**** BEGIN LOGGING AT Thu Mar 26 03:04:32 2020 Mar 26 03:05:00 Right. I found a bit of info. on the chip but not much. I wonder if MattB0ne wants one. I wonder, wonder. Mar 26 03:06:04 GenTooMan: I am trying to get some answers from Seeed Studio forums now. I wonder if they know first hand. Mar 26 03:06:37 I do not, I repeat, own one. I am lifeless in this issue right now. Mar 26 03:07:29 The year '17 had a kernel driver for it, presumably. I think that is dated now. At least, I read this in chat one day. Mar 26 03:08:51 zmatt said the green is interchan Mar 26 03:09:07 Where would the driver be located in the kernel on github? Mar 26 03:09:08 buuuuuttt your point about the year is well taken Mar 26 03:09:47 MattB0ne is back! Sorry to chat about you while you were away. Mar 26 03:11:43 I am currently searching the kernel for drivers for HDMI but I came up short. Should I search for frame buffer instead? Mar 26 03:12:41 was reading on qt Mar 26 03:12:59 hopefully someone responds you your post Mar 26 03:13:08 Yep. I will wait to see. Mar 26 03:13:22 there's is a vendor that supposedly has great customer service may give them a ring on their displays Mar 26 03:13:32 a bit pricey but I will spend the $$$ Mar 26 03:14:52 newhavendisplay Mar 26 03:15:01 seem to have nice stuff Mar 26 03:17:46 I found the newer version of IT here: https://github.com/torvalds/linux/blob/master/arch/arm/include/asm/hardware/it8152.h. Mar 26 03:18:16 That is the header file for the chip in the supported version. Mar 26 03:19:05 I guess we, me mostly, can wait until I learn how to better type up kernel drivers before promoting this cape. Mar 26 03:21:53 I wonder if bringing back the old driver would prove valuable...heh? Mar 26 03:24:41 I know! Mar 26 03:28:36 You can steal it from the old kernel and Debian OS, place it on the board, and add the driver w/ whatever, i.e. I found some dated info. but it may prove useful. Mar 26 03:28:38 ... Mar 26 03:28:56 http://derekmolloy.ie/writing-a-linux-kernel-module-part-1-introduction/ might help too. Are we still talking about this idea? Mar 26 03:29:29 it is still on the table Mar 26 03:29:41 looking for path of least resistance though Mar 26 03:30:03 Regarding QT a lot of 'soft'ware people seem to go crazy over it, however I've never seen the point of it. It seems religious belief has become more important than pragmatism in software. Mar 26 03:30:06 Oh. I say the messier, the better. Mar 26 03:30:41 "The horse jumped in mud!" and then... Mar 26 03:30:47 I think you may have to see what driver is in the image that seeed studios provided. Mar 26 03:30:48 "The horse took a shower." Mar 26 03:30:56 Right. Mar 26 03:31:11 So, first... Mar 26 03:31:13 The primary difference I can see is the I2C configuration of the device. Mar 26 03:31:27 THey have some DIP switches on it. Mar 26 03:31:56 the dip switch is to select the cap I2C eeprom ID Mar 26 03:32:03 cap == cape Mar 26 03:32:05 Oh. Mar 26 03:32:06 Okay. Mar 26 03:32:11 You did read the schematics? :D Mar 26 03:32:15 No. Mar 26 03:32:23 I am mad right now. Mar 26 03:32:45 I went over the setup guide and MattB0ne left and came back. Mar 26 03:32:53 I could not keep up. Mar 26 03:32:57 Ah... well it's almost identical except what IC they used for the HDMI framer. Mar 26 03:33:04 Hmm. Mar 26 03:33:07 Okay. Mar 26 03:33:33 The only difference I can foresee is configuration of the HDMI framer may be different. Mar 26 03:34:05 So, the resolution might be a bit off or the imaging may be skewed slightly? Mar 26 03:34:33 I might have to get one. Wait for me! Mar 26 03:34:47 no it just might not recognize it has an HDMI framer attached because it can't recognize the device. Mar 26 03:34:48 lol Mar 26 03:34:55 Oh. Mar 26 03:35:10 you figure this would be easier Mar 26 03:35:20 NOpe! More fun, mo' betta'. Mar 26 03:35:25 set_ did you just say you might have a skewed image? Mar 26 03:35:35 maybe I just get a black Mar 26 03:35:49 Mentally, of course. But on my LCD, no way. Mar 26 03:36:11 Well just need to compare the 2 IC's register set I suppose. Mar 26 03:36:31 Oh. To see which pins go where? Mar 26 03:37:06 or to change the source to fit the new, updated IC mappings? Mar 26 03:38:14 how common is it to write your own kernel. Mar 26 03:38:19 Very! Mar 26 03:38:24 LKM, you mean? Mar 26 03:38:55 LKM = Linux Kernel Module or library! Mar 26 03:39:07 GenTooMan: I just got started with qt because of the Molloy book. the creator seems nice though Mar 26 03:39:43 set_: looking at that Molloy link whatever that is Mar 26 03:40:00 It is how to install your own LKM. Mar 26 03:40:12 why would they need that Mar 26 03:40:19 to make the LCD work Mar 26 03:40:22 Now...do not quote me. Things change rapidly. Mar 26 03:40:42 B/c the chip is "outdated" and the new kernel does not support the "outdated" chip. Mar 26 03:41:09 kk Mar 26 03:41:47 I am just thinking about something. Mar 26 03:42:11 Things change. I am never bleeding edge on Tech. but I like new stuff. Mar 26 03:42:24 well I have to hit the hay, hunting for toilet paper early tomorrow Mar 26 03:42:33 Maybe we two should write a LKM for the chip? Mar 26 03:42:36 Ha. Mar 26 03:42:38 Good luck. Mar 26 03:42:44 I have not found any in a week. Mar 26 03:43:06 I will read what you posted and will report back Mar 26 03:43:22 Yea. I always wanted to work w/ someone on a project. Mar 26 03:43:23 got to go at first light with the trucks Mar 26 03:43:24 Thank you. Mar 26 03:43:29 Okay. Mar 26 03:43:32 laterz Mar 26 03:43:38 BBB! Mar 26 03:44:03 I feel like a syncronized my watch today. Odd. Mar 26 03:44:10 mattb0ne don't get me wrong QT is OK but those who use it tend to be overzealous Mar 26 03:44:28 set_ one way to be even Mar 26 03:44:59 Ha. I have been trying to work w/ people on this LKM installation for years. I might get my shot. Mar 26 03:45:49 Oh and I saw the info. posted on the google groups page about the New Year resolution. Mar 26 03:45:52 Nice! Mar 26 03:46:02 LKM, here I come! Mar 26 03:54:52 MattB0ne: If you read this idea, please download the image on the...scratch that. I will do it. Mar 26 03:59:06 I wonder if that image will boot so I can get into the firmware section of the file system. Mar 26 04:03:09 I wish they would have specified what module was needed to run it instead of just giving an image for it. Mar 26 04:03:43 I would say so. Mar 26 04:04:10 Now, I need to flash, dig, and do something else to extract the data. Mar 26 04:04:50 GenTooMan: I got the schematic open ow. Mar 26 04:04:54 ow = now Mar 26 04:05:15 Sorry. Datasheet. Sheesh. Mar 26 04:05:24 I have the datasheet open now. Mar 26 04:08:18 So, the pin config of this chip is listed as 64 pins w/ some GND pad for 65. Mar 26 04:09:57 GenTooMan: Sorry about earlier. I got excited. Mar 26 04:14:23 I need to corelate the pins. I'm very sleepy however, and I have to get up early. It's past 12AM here so zmatt should be waking up in about an hour. Mar 26 04:14:31 that said good night Mar 26 04:14:59 Ha. Okay. Later man. Mar 26 04:30:59 lol what, you think I'm someone who generally wakes up at 6am ? if I'm awake at this hour it's because I haven't gone to bed yet Mar 26 04:31:31 what's the question? Mar 26 04:33:23 I tried to skim scrollback but I have absolutely no idea what it's all about Mar 26 04:34:50 6 a.m! Mar 26 04:35:13 well it's 5:35 Mar 26 04:35:29 Me and the MattB0ne fellow are going to write up a LKM for the IT66121. Mar 26 04:35:53 that seems highly unlikely Mar 26 04:35:55 Well, we are going to try to steal it from an old kernel and apply it to the newer images/kernel/OS. Mar 26 04:35:59 No? Mar 26 04:36:18 okay that's already more probably, but still not very likely :P Mar 26 04:36:27 Dang it! Mar 26 04:36:53 The HDMI Cape needs a second coming for the MattB0ne fellow. Mar 26 04:37:08 I am going to get one and try to update the firmware for the updated kernel. Mar 26 04:37:51 Is the HDMI Cape "busted" for life now? Mar 26 04:38:12 I am trying to deal w/ people on the Seeed Studio forums to find out. Mar 26 04:38:15 there's a hdmi cape with that thing on it? but also, he has a beaglebone green. why on earth would one get a green and then add a hdmi cape, then you might as well have gotten a black Mar 26 04:38:31 Right. Mar 26 04:38:38 But...that is not how things happened. Mar 26 04:38:45 I want to learn too! Mar 26 04:39:38 He had a BBB and then a BBG and now needs pins after having HDMI support (I think). Mar 26 04:39:54 I just want to pitch in and learn things. Mar 26 04:40:27 The BBB is the cure but not the fun route. Mar 26 04:40:56 "It's alive!" Mar 26 04:43:02 what kernel are they even using that supported this thing, it doesn't even seem to be in the 3.8-bone kernel series Mar 26 04:43:12 Well, the rebirth is alive. The rebirth of the HDMI Cape! Mar 26 04:43:17 Please hold. Mar 26 04:43:22 I will get the image I downloaded. Mar 26 04:43:33 I'd just leave it dead and buried Mar 26 04:43:51 Fine. Mar 26 04:43:55 Sheesh. No fun. Mar 26 04:44:36 Well, I guess I will tell MattB0ne in the morning or tomorrow afternoon. Mar 26 04:44:52 BBB! Mar 26 04:45:31 It sounds like a bunch of learning and fun. Mar 26 04:45:32 especially since the datasheet doesn't even contain enough information to write a driver. I'm guessing sufficient documentation is probably only available until NDA Mar 26 04:45:40 *under NDA Mar 26 04:45:44 NDA? Mar 26 04:45:58 non-disclosure agreement Mar 26 04:46:03 Boo! Mar 26 04:46:05 it's seeeekrit Mar 26 04:46:10 Double Boo! Mar 26 04:46:59 Hmm. Well, I will see what the forum people say and tally the pros and cons. Mar 26 04:47:17 Who knows? It may be something to relish on for a bit and then act. Mar 26 04:47:59 a driver was submitted to mainline about two weeks ago it seems Mar 26 04:48:04 Heh? Mar 26 04:48:09 Say that again? Mar 26 04:48:17 note: submitted, not accepted :P Mar 26 04:48:20 A driver for the chip. Mar 26 04:48:22 Dang it! Mar 26 04:48:23 it got plenty of commentary Mar 26 04:48:28 Gimme! Mar 26 04:48:37 I found what is currently accepted only. Mar 26 04:49:14 Some other ITxxxx in arch/arm/ Mar 26 04:51:55 anyway, maybe once it's in mainline someone could try to backport it Mar 26 04:52:07 https://github.com/torvalds/linux/blob/master/arch/arm/include/asm/hardware/it8152.h is what I found. Mar 26 04:52:26 Oh. yea. it would be nice. Mar 26 04:52:41 Then, I could just add it to my firmware files. Mar 26 04:52:47 that is absolutely not even the tiniest bit related Mar 26 04:52:53 Oh. Mar 26 04:53:00 What did I find? Mar 26 04:53:15 For separate boards? Mar 26 04:54:03 dunno, some funky pci-related chip Mar 26 04:54:17 a normal driver wouldn't be in arch/ anyway Mar 26 04:55:09 Oh. Okay. Hmm. Where did you find the info. on the driver IT66121? Mar 26 04:55:18 google Mar 26 04:55:22 Ha. Mar 26 04:55:25 Okay. Off to look. Mar 26 04:55:47 the mailing list thread is titled "Add it66121 driver" Mar 26 04:57:09 I found it. Mar 26 04:57:41 It seems people are already knowledgeable on the it66121 and want back in w/ this chip. Mar 26 04:59:22 I found some info. and the drm driver. Yikes! Mar 26 04:59:43 For one small chip to work, they need all that source. Sheesh. Mar 26 04:59:46 (note: drm = direct rendering manager, the graphics subsystem of the linux kernel) Mar 26 04:59:56 oh. Mar 26 05:00:19 So, each patch is for something separate. Mar 26 05:02:39 Could a dt binding advance this search. I see they have one example to test. Mar 26 05:02:55 pineapple Mar 26 05:03:10 Sorry. Mar 26 05:03:13 (I figured I'd give an answer that makes about as much sense as your question does, and usually do) Mar 26 05:04:08 Yea, yea. I know. I am advancing in searching on how to make the HDMI Cape to become in working order. Mar 26 05:04:10 So... Mar 26 05:04:30 If it happens in mainline, I might have a chance w/ someone porting it to an older kernel? Mar 26 05:05:47 Just to say, xfce4 BBBs would be neat in a setup box and w/ keyboard, mouse, and graphics for sewer inspection. Mar 26 05:07:09 I could cut out most of everything accept for a video feed, maybe. Who knows? Mar 26 05:07:24 Anyway... Mar 26 05:07:32 @zmatt: Thank you. Mar 26 05:07:48 I needed to know that sometimes things go awkward for a good reason. Mar 26 05:08:05 Maybe that chip does not need to be in the mix for now. Mar 26 05:08:09 Who knows? Mar 26 05:10:38 Signing off. I feel like I caused more than one man can fathom, i.e. even w/ a mask on. Mar 26 12:10:16 m Mar 26 12:52:15 Hello Mar 26 12:53:08 Any promo images for Beaglebone Ai? Mar 26 13:09:39 umm http://beagleboard.org/ai ? Mar 26 13:36:15 I been on the page but there isn't a gallery of images Mar 26 14:53:10 So today's issue is I plug in a mini-box DCDC-USB module and the Black says "usb_submit_urb(ctrl) failed: -1", and I can't communicate with it. That latter makes sense, but so far my search foo has yet to produce the tiniest clue, much less an answer. Can anyone point me in a direction? Mar 26 14:53:25 This in the front USB ofc, the A one. Mar 26 15:08:58 I have seen if one is able to set usbquirks it can be worked around, but nothing on how to do that on a Black, either. Well it's a kernel parameter, which I'm sure is simple enough, but my feeling is there are multiple options for that, and I can't verify which I may need. Mar 26 15:43:17 Hello Mar 26 15:43:34 I would like to have information about your Green board Mar 26 15:44:04 is it possible to be adapted with external wifi and sim modules? if so, do you sale those? Mar 26 15:46:43 and also, can we do a 5 or 7 inches screen adaptation? do you have that service to adapt it for us? Mar 26 15:51:16 Sayde: ask sen_ he is researching it now Mar 26 15:51:28 set_ I meant Mar 26 17:31:45 Sayde the green board is seeed studios not beagleboard.org I suggest you examine the originators website they often have VERY detailed information on them. Mar 26 17:33:39 (unless you're looking for which expansion header pins are in use on the green-wireless :P ) Mar 26 17:39:19 * GenTooMan hangs his head in shame. Mar 26 18:22:24 Is there an alternative to lsusb for the Black? I don't seem to have that package. Mar 26 18:39:23 Ragnorok: sudo apt-get install usbutils Mar 26 18:39:47 (that's the package containing lsusb) Mar 26 18:40:25 \o/ Thanks zmatt. So the device exists. That's good. Mar 26 18:40:56 I thought it might. /sys/bus/usb/drivers/usbhid shows an entry as well. Mar 26 18:47:05 When I plug it in, dmesg has "usb 1-1: string descriptor 0 read error: -71". I get the same error -71 from usb_set_configuration in their sample code, but I can't find anything that says what that code is. It does however seem to do usb_open() okay. Mar 26 18:55:11 I just ran update_kernel.sh and it says it's "upgrading" to 3.8.10-bon86. ?? Ah. That's the only one listed "stable". Guess more search foo. Mar 26 19:05:41 If I only had a memory I'd know how to do this. lol I've done it before. Mar 26 19:17:48 3.8 wtf? what ancient system are you using? Mar 26 19:18:16 update_kernel normally updates your kernel to the latest within your current kernel series Mar 26 19:19:06 you can give it commandline options to switch kernel series (or just install a kernel of choice using apt), though if your system is ancient enough to use kernel 3.8 then updating the kernel would probably break your system Mar 26 19:19:19 I'm on 4.1.19-bone20, but it's trying to "upgrade" to 3.8.x. I was wanting to move up from there to see if this USB issue is resolved. Mar 26 19:19:59 that makes no sense... that's with just invoking the script without any arguments? Mar 26 19:20:05 Correct. Mar 26 19:20:27 info: you are running: [4.1.19-bone20], latest is: [3.8.13-bone86] updating... Mar 26 19:20:50 I stopped it while it was GETting. Mar 26 19:21:31 that sounds like reason for a bug report, though you should first try git pull in /opt/scripts Mar 26 19:21:43 Roit toe. Mar 26 19:21:47 however kernel 4.1 is a dead series, it hasn't been maintained in years Mar 26 19:25:35 the most recent 4.1-bone kernel package is linux-image-4.1.38-bone24 released 2017-01-20 Mar 26 19:28:03 I understand. I was going to finally give the latest a try and see what's heinously mangled. Mar 26 19:28:26 I expect it'll be horrid, but hey. It could work. Mar 26 19:30:37 We're largely in the "if it ain't broke don't fix it" category. These units are almost exclusively on a tightly controlled network, or not connected to any network. But if it fixes some issues we're having, perhaps I can convince The Bean Counters to let me bit that bullet and update the kernel. Mar 26 19:40:20 bb-kernel/braches has two sets. If I'm coming from that ancient version is there a reason I'd select "rt", or not select it? Mar 26 19:53:43 no Mar 26 19:54:07 Roit toe. Here goes nuttn' Mar 26 19:54:29 heh, out of curiosity I made an overview of all bone/ti kernel packages currently on rcn's debian repo: https://pastebin.com/jsSTSG9J ... there are definitely some oddities in there Mar 26 19:55:31 I'm going to start w/ 4.20.15-bone10. If that doesn't screw the pooch I'll try a 5.something. Mar 26 20:00:14 I suck at git. I thought I cloned the 4.20 repo but the dir has no buildy things in it. (pout) Mar 26 20:01:18 ehh why those? Mar 26 20:01:24 4.14 is the current default release Mar 26 20:01:33 4.19 is the next default release Mar 26 20:01:40 4.20 is not an LTS kernel Mar 26 20:01:53 Why all the others? 5.x and all? Mar 26 20:01:58 and in fact 4.20 is already unmaintained Mar 26 20:03:36 I've spent three hours searching and you are the first one to bring that to light. Mar 26 20:03:51 I added a summary to the top of https://pastebin.com/jsSTSG9J Mar 26 20:04:43 note how the latest 4.19-bone release was this month, while the latest 4.20-bone release was a year ago Mar 26 20:05:10 Roit. Mar 26 20:05:23 LTS series are exactly the ones that have a -ti kernel Mar 26 20:06:41 I'm assuming it's simpler to stick with a bone than a ti. I'm thinking I should play it safe with 14 since it's the default now. Mar 26 20:06:47 4.19 is probably fine, 5.4 might be living on the edge Mar 26 20:07:12 I'm still using 4.14-bone, I should really start testing 4.19-bone Mar 26 20:08:04 note that the -ti series have been the default for years now so they'll be more tested than -bone kernels Mar 26 20:08:16 (but -bone kernels are closer to mainline) Mar 26 20:08:23 Everything seems to point to https://github.com/RobertCNelson/bb-kernel.git but when I clone that I don't get anything I can execute. Mar 26 20:09:34 Ragnorok: as in lines 8-9 of https://pastebin.com/eLhrp1Hg ? ;) Mar 26 20:09:58 why do you need to build a custom kernel btw? Mar 26 20:10:25 I don't strictly, but I do need to build a kernal module against whatever kernel I use. Mar 26 20:10:33 ah Mar 26 20:10:43 I don't suppose dkms works? Mar 26 20:10:55 Dunno what a dkms is. Mar 26 20:11:04 https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support Mar 26 20:11:42 I'm sure it will, if The Bean Counters say to invest the time to change how our system is implemented now. Mar 26 20:12:07 it may be faster to cross-compile it anyway Mar 26 20:12:23 I intend to. I have a dev env I'm trying to clone to. Mar 26 20:12:50 for custom drivers I just add local patches to my fork of bb-kernel Mar 26 20:12:59 It seems like your latest pastebin suggests download, then modify system.sh.sample, then build, rather than clone? I had no .sh when I cloned. Mar 26 20:13:10 no I don't Mar 26 20:13:13 you misread Mar 26 20:13:21 That's why I asked. (wink) Mar 26 20:14:10 My attempts to "pick a branch" have borne no fruit. Mar 26 20:14:18 ? Mar 26 20:14:45 https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.14 Mar 26 20:14:54 system.sh.sample is right there, as is build_deb.sh Mar 26 20:15:15 I'm at the 4.19 branch on github. I can't figure out how to tell it to clone that branch. Mar 26 20:15:48 while cloning you can pass -b am33x-v4.14 or after cloning you can do git checkout am33x-v4.14 Mar 26 20:15:48 So you're saying I should download them and run them, and not clone it? Mar 26 20:15:53 no I'm not Mar 26 20:16:06 Ah. -b. I'll try that then. Mar 26 20:16:29 I'm showing that that branch contains both the system.sh.sample you need as well as the script you run (in reference to your "I don't get anything I can execute") Mar 26 20:16:44 hence both of those will be there after checking out that branch Mar 26 20:17:09 I didn't have -b b/c I didn't know to use it, b/c I have no git foo and it's not spelled out on that branche's page. (shrug) Mar 26 20:17:29 zmatt: Hi, can you see my messages? Mar 26 20:17:33 Cloning now. Mar 26 20:17:39 you don't need -b, like I said you can just do "git checkout am33x-v4.14" like you normally would to switch branch Mar 26 20:17:42 lorforlinux: yes Mar 26 20:17:47 why? Mar 26 20:18:04 if by "messages" you mean that question Mar 26 20:18:26 I was messages you for 5 days on the group but i didn't get any reply, i was using riot.im. Mar 26 20:19:38 I don't know what group you're referring to or what riot.im is. if you tried to msg me here on irc then you failed since I didn't receive any, though I request you just ask questions in chat anyway and don't send me private messages Mar 26 20:20:19 I literally messaged the question "can you see my message" 3 times today, before logging in using https://webchat.freenode.net/ Mar 26 20:20:30 I sent all the messages on #beagle only. Mar 26 20:22:36 lorforlinux: here's the last 21 hours of IRC log: https://pastebin.com/x1jbR8tY Mar 26 20:22:37 lorforlinux: This is the first I've seen anything as well. Mar 26 20:25:26 why did we have that... Mar 26 20:25:56 I feel so bad now :( I should now have used riot (I was using that because all the mentors and students using the same for GSoC) i will paste all the messages i sent on riot.im here. Mar 26 20:26:14 anyway, I don't see any channel modes or +q modes that could be blocking messages (we've had restrictions on messages from unregistered users in the past, due to spambots) Mar 26 20:26:23 note that this is the wrong channel for GSoC Mar 26 20:26:34 (and I'm not involved with it) Mar 26 20:26:49 there's a separate #beagle-gsoc channel Mar 26 20:27:17 please use the gsoc channel Mar 26 20:27:33 this is a community/support channel Mar 26 20:27:59 I've suggested lorforlinux get some feedback from some experts here on his approach. Mar 26 20:28:04 ok Mar 26 20:28:05 zmatt: i know this is not the channel for GSoC i just wanted some feedback and help regarding the project i am proposing to do this summer under jkridner. I hope that's okay? Mar 26 20:28:14 sure Mar 26 20:28:36 for sure the Riot/Matrix bridge to Freenode has been a real pain . Mar 26 20:29:14 The project is to try to come up with some tools to help people migrate support for capes between BeagleBone Black and BeagleBone AI. Mar 26 20:29:19 lorforlinux: also if you want to share multi-line text, use a paste service like pastebin.com Mar 26 20:29:27 don't paste multiple lines into chat Mar 26 20:30:49 zmatt: okay i will gather all the messages and share a link with you shortly. Mar 26 20:31:53 jkridner: I still need to find a moment to test my idea to allow DT-based (including overlays) pinmux to work glitchless on the am572x Mar 26 20:32:13 (by letting u-boot gather the info and then briefly reenter I/O isolation mode) Mar 26 20:32:56 zmatt: that'd be incredible... and certainly used in this GSoC project. Mar 26 20:33:34 I've been suggesting creating aliases for various peripherals such that cape overlays can simply reference those aliases, rather than the peripherals themselves. Mar 26 20:33:57 lorforlinux created some pinmux setting definitions that rcn-ee already merged. Mar 26 20:33:58 someone from TI claimed something that would be really nice if true, but he said he'd have to double check (but he never followed up on it) and I haven't had a chance to test it yet: https://e2e.ti.com/support/processors/f/791/p/855335/3164951 Mar 26 20:35:09 NishanthM: I was promised a long time ago a document that describes the limitations of the AM5 pinmux so that such work-arounds could be explored by the community. Do you know if such a doc really exists? Mar 26 20:36:09 being able to have a proper mental model of what's going on would be awesome Mar 26 20:36:24 jkridner: I worked on writing aliases yesterday and rcn tried the patch but it was not successful. Instead of aliases he suggested me to use symlinks for the peripherals. Mar 26 20:36:32 see this -> https://github.com/beagleboard/BeagleBoard-DeviceTrees/pull/11 Mar 26 20:37:32 lorforlinux: putting stuff in /aliases is not very useful Mar 26 20:37:41 those can't be referenced in any useful way by overlays Mar 26 20:38:33 pretty much the only use for /aliases is that it affects the numbering of linux devices (for some but unfortunately not all device types), e.g. spi bus numbers and i2c bus numbers Mar 26 20:38:40 and messing with those globally sounds like a bad idea Mar 26 20:39:15 symlinks are useful for userspace, but what about overlays? Mar 26 20:39:37 you can add extra labels to devices Mar 26 20:39:42 *nodes Mar 26 20:39:58 oh, more than one label? is that not what an alias is? Mar 26 20:40:11 well, sounds like that might be the thing then. Mar 26 20:40:27 just wanting to have labels in a different namespace to avoid collisions. Mar 26 20:40:38 no, /aliases is an unrelated mechanism that's used at runtime. labels originally only existed at compile-time (prior to overlays) Mar 26 20:40:52 a "cape" has an idea of what I2C bus is on certain pins, but the peripheral might be different based on board routing. Mar 26 20:40:54 yeah, a bone_ prefix sounds reasonable Mar 26 20:41:18 see lorforlinux, I knew asking zmatt was a good idea. :-D Mar 26 20:43:15 zmatt: we have an aliase for i2c0 = &i2c0 in BeagleBone Black device tree, what is the use case of that aliase? Mar 26 20:44:17 btw, if you want to make overlays less painful to maintain, maybe also consider borrowing the perl script from my overlay-utils project that allows overlays to be written in normal dtsi syntax instead of the horrid structure of overlays ;) https://github.com/mvduin/overlay-utils (look at its examples and compare them to bb.org-overlays and you'll see what I mean. apologies that my pinmux macros ... Mar 26 20:44:23 ...are different from mainline, I created them independently back when mainline mostly still used magic hex values iirc) Mar 26 20:44:40 lorforlinux: it picks the i2c bus number that linux will assign to it Mar 26 20:45:04 jkridner: yes <3 i am gald i realized that my messages are not getting to him before the end of application perod. zmatt: you are awesome =* Mar 26 20:48:14 (e.g. https://github.com/mvduin/overlay-utils/blob/master/can0.dtsi is how my tools let you write an overlay that's equivalent to https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-CAN0-00A0.dts apart from missing the metadata, which you can add if you want but u-boot ignores it anyway) Mar 26 20:48:55 lorforlinux: can you incorporate in the schedule migrating bb.org-overlays to zmatt's approach and align any update that'd need to be sent to mainline? Mar 26 20:49:03 lorforlinux: let me know if you have confusion on what mainline is. Mar 26 20:49:27 I don't think mainline would be interested in anything in my repo Mar 26 20:49:36 zmatt: by picking up the i2c number assigned by linux you mean that the i2c0 will point to the i2c0 node we define in device tree right? are we using that alias in anyway for overlays? Mar 26 20:49:51 if anything I should probably use mainline macros... it's just that I like mine better :P Mar 26 20:50:50 zmatt: why do you use part codenames? Mar 26 20:51:31 lorforlinux: I meant that the linux i2c bus device corresponding to the referenced DT node (&i2c0) will have bus number 0 (i.e. it will show up as /sys/bus/i2c/devices/i2c-0 and /dev/i2c-0 ) Mar 26 20:51:51 I just wouldn't want any changes to bb.org-overlays that wouldn't work against mainline. Mar 26 20:52:18 jkridner: because they're clearer than part numbers. often the same chip has multiple wildly different part numbers, some of which look very similar to wildly different SoCs Mar 26 20:52:52 jkridner: I wasn't suggesting you use my macros, I was suggesting you use my perl script (which converts dtsi snippets into overlay structure) Mar 26 20:53:06 k. Mar 26 20:53:20 basically it performs this transformation: https://pastebin.com/b8kZfhRG Mar 26 20:53:43 jkridner: mainline is our master branch aka current linux image OR other related code right? Mar 26 20:54:16 it would also let you modularize overlays, e.g. they could #include a snippet that sets up some device and its pinmux, and you could then just recompile the same overlay against a different set of snippets for the bbai Mar 26 20:54:22 when we say 'mainline', we are generally speaking of the Linux kernel mainline source on git.kernel.org Mar 26 20:54:47 specifically, 'torvalds' Mar 26 20:54:53 okay got it :) Mar 26 20:55:44 https://kernelnewbies.org/FirstKernelPatch Mar 26 20:56:11 zmatt: I will ask the questions again here, instead of sharing a previous message log. Mar 26 20:56:33 jkridne: thanks i started reading that already :) Mar 26 20:58:53 I want to assign names to header pins of BeagleBone AI. I have already talked to jkridner and rcn on this, now i know that we can not use "gpio-of-helper" binding for pin naming on AM58xx what could be the other possible solution for naming pins? Mar 26 21:01:10 jkridner: here's the literal translation of https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-CAN0-00A0.dts into overlay-utils syntax without changing any of its content (in particular using mainline pinmux macros): https://pastebin.com/nAtkTQ23 Mar 26 21:01:19 jkridner: that should make it clearer what my script does Mar 26 21:02:59 lorforlinux: what do you mean? gpio-of-helper works perfectly fine on AM572x, it's completely hardware-independent Mar 26 21:03:38 Is it the right place to assign the libgpiod names? Mar 26 21:04:19 I get confused on what to call the two different names... the one that describes the processor signal and the one that describes the board-level function. Mar 26 21:04:38 oh I dunno, I'm talking about the more common (and more useful) sysfs interface Mar 26 21:04:40 zmatt: yes i analyzed the code and it doesn't depend on the hardware but rcn told me that it is not a good idea to use it on AM572x. Mar 26 21:04:52 lorforlinux: I'd love to know why Mar 26 21:05:48 zmatt: I am dying to know why can we use it? I am working on that one for more than 2 weeks now, didn't find any reason for not using it! Mar 26 21:06:00 *can't Mar 26 21:06:20 we keep getting pushed to use these dang libgpiod names. not my favorite thing in the world either. no idea why they are trying to push us away from sysfs. Mar 26 21:06:25 lorforlinux: I know some people are pushing for the new gpio chardev, but I consider it to be a completely unsuitable replacement for the sysfs interface Mar 26 21:07:25 * jkridner doesn't remember if gpio-of-helper does anything related to pinmux. I think not. I think rcn-ee might be thinking we don't want it because we can't dynamically pinmux. Mar 26 21:07:44 gpio-of-helper has nothing to do with pinmux, that's bone-pinmux-helper Mar 26 21:07:52 zmatt: what is this game between libgpiod and sysfs? Mar 26 21:09:13 jkridner: yes after reading his message several time i am thinking of the same. He might be thinking that i want to use it for pin-muxing. I should clarify on that with him. Mar 26 21:09:45 I had a long conversation about this recently with someone (trying to remember who...) .. I should try to dig it up Mar 26 21:11:19 ah with pdp7 Mar 26 21:12:55 zmatt: yes, it was :) Mar 26 21:14:21 pdp7: have you checked out the GSoC proposals? Mar 26 21:14:31 no, where? Mar 26 21:14:34 zmatt: what is stopping us to do dynamic pin muxing on AM572x/dra7x ? Mar 26 21:14:52 proposal list: https://elinux.org/Category:GSoCProposal2020 Mar 26 21:15:27 lorforlinux: http://www.ti.com/lit/er/sprz429l/sprz429l.pdf page 57 (erratum i869) Mar 26 21:15:29 also, pdp7, this is where I'm trying to work on the description for our meeting on Tuesday: https://elinux.org/Mikrobus Mar 26 21:16:17 ok, thanks Mar 26 21:16:21 I just struggle with expressing the right clarity on what is "platform bus" and why doesn't the data structure allow us to enumerate any I2C devices. Mar 26 21:16:35 (also erratum i933 on page 86, although iodelay can probably be ignored for the slower-speed interfaces most commonly used by people who use dynamic pinmuxing) Mar 26 21:17:09 https://programming.vip/docs/principle-of-platform-platform-bus-driven-by-linux-device-3.html doesn't look definitive enough. Mar 26 21:17:25 REPL for PRU... interesting Mar 26 21:17:46 pdp7: with py-uio you mean? Mar 26 21:17:48 zmatt: my thought too.... we should really only care about iodelay for a select higher-speed mode of any given pin. Mar 26 21:18:07 pdp7: I'd think they should re-tackle pruspeak/botspeak for that. Mar 26 21:18:51 doing dynamic code generation in py-uio is something I still want to work on... but I continuously have more things I want to work on than time and energy to do so :P Mar 26 21:19:10 oh... and this one: "This project will enable the control of the Beaglebone's PRUs using remoteproc and rpmsg driver rather than using uio drivers" Mar 26 21:19:12 nice Mar 26 21:19:14 hmmmm.... need to get some py-uio examples into cloud9-examples, PRU Cookbook and other resources. Mar 26 21:19:16 Project name: Port am335x_pru_package to remoteproc Mar 26 21:19:57 rpmsg... for all PRU users who don't actually care about performance and determinism :D Mar 26 21:19:59 * jkridner thinks loading via remoteproc, low-speed messaging with rpmsg and any fast stuff should still go over UIO. Mar 26 21:20:21 zmatt: are you against using remoteproc for loading? Mar 26 21:21:16 jkridner: I mean, doing that in the kernel is more limited, harder to maintain, and doesn't seem to have any real benefit for us Mar 26 21:21:38 it's also useless if you want to do things like dynamic code generation Mar 26 21:22:07 and it doesn't support pasm binaries (py-uio supports both raw binaries produced by pasm and ELF executables produced by clpru) Mar 26 21:22:59 it's also useless if you want to do stuff like invasive debugging (breakpoints / single-stepping), which requires dynamically modifying code and inspecting/modifying the core state Mar 26 21:23:32 zmatt: page 57 and 86 provided good insights, thanks. Mar 26 21:23:34 zmatt: why doesn't this feedback enter the mainline discussion? Mar 26 21:23:37 (py-uio has an example that shows how to do these things: https://github.com/mvduin/py-uio/blob/master/pru-examples/debugging.py ) Mar 26 21:24:59 known-good ELF parsing is a nice thing. reasonably well documented interface with one upstream for bug fixes. Mar 26 21:25:38 debugging support indeed is a tough one for upstream, but I do wonder if it could be made more general under remoteproc. Mar 26 21:26:16 I'd think debugfs would open up a lot of possibilities for register dumps and single stepping. Mar 26 21:26:24 remoteproc just has a very different mental model of how auxiliary cores are used I think... they think of it more like firmware loading onto devices Mar 26 21:27:21 rather than something that's being used directly as development target by the user Mar 26 21:27:23 sure. I've wasted a lot of mental energy in trying to enable people to work better with remoteproc. It'd be nice to know if it really is a waste. Mar 26 21:27:53 * jkridner has a number of distractions here and won't be around much longer. Mar 26 21:30:09 and of course from a security point of view there's a clash of worlds too... linux devs think that access to these devices needs to be locked down hard because of system security, and our images subsequently allow the default unprivileged user write access to those firmware images ;) Mar 26 21:31:00 which makes perfect sense since our systems typically have only a single user, who also has physical access to the hardware Mar 26 21:32:53 jkridner: the reaction kremlin's pru driver for openbsd received is also a perfect illustration of this clash of worlds: http://openbsd-archive.7691.n7.nabble.com/armv7-introducing-tipru-4-td299789.html#a300121 Mar 26 21:38:35 zmatt: can you please have a look at my proposal and let me know what you think? https://elinux.org/BeagleBoard/GSoC/2020Proposal/DeepakKhatri Mar 26 21:39:54 Also, can you let me know If the project is successfully completed, what will its impact be on the BeagleBoard.org community? Mar 26 21:40:28 I'm not a suitable person to ask that second question Mar 26 21:42:19 jkridner: suggested me to get your thoughts on that as you are very knowledgeable about the BeagleBone hardware. Mar 26 21:43:13 though I feel I must point out that unless my idea to have u-boot do glitchless DT-based pinmux works (and is actually implemented), the usefulness of this seems limited. the pinmux glitching issue doesn't just affect dynamic pinmuxing by bone-pinmux-helper, it affects all pinmuxing done by the kernel Mar 26 21:44:42 right now the only way to do glitch-free pinmux is by changing hardcoded pinmux tables that are compiled into u-boot Mar 26 21:45:02 needless to say, having to recompile the bootloader to change pinmux is.. inconvenient Mar 26 21:45:49 just inconvienent> Mar 26 21:46:15 I'd go as far as calling it _quite_ inconvenient Mar 26 21:47:57 reminds me of a description on how to get out of protected mode on the 286, "very inconvenient, you have to reset the processor.." another was "shoot yourself in the head clear your mind out of rational thinking." Mar 26 21:47:58 of course it's an option to simply hope glitchless DT-based configuration will eventually work and accept the risk of glitches for now Mar 26 21:48:33 Okay we should we keep the pinmuxing part in "maybe" region for the GSoC proposal right? Mar 26 21:51:31 I haven't read it in detail yet... I'm trying to understand what it's saying Mar 26 21:54:37 honestly I think step 1 is documenting correspondences between interfaces on the BBB P9/P8 headers and those on the BBAI P9/P8 headers. Mar 26 21:54:56 for example I made this regarding McASP: https://docs.google.com/spreadsheets/d/e/2PACX-1vR_yw3T67jWc4I7mjxl3NAyeFClZ_k27cvOWEuryKeA_5LTABJ54xelpHAtf8zXO3iLmN7K55Se5tHV/pubhtml?gid=1779159674&single=true Mar 26 21:55:45 (only a single ioset of BBB mcasp0 has an equivalent on the BBAI, and BBB mcasp1 has none) Mar 26 21:57:15 or this one for the LCD interface: https://docs.google.com/spreadsheets/d/e/2PACX-1vR_yw3T67jWc4I7mjxl3NAyeFClZ_k27cvOWEuryKeA_5LTABJ54xelpHAtf8zXO3iLmN7K55Se5tHV/pubhtml?gid=1441290740&single=true Mar 26 21:58:01 Yes, the interface chart for header pins is a good plan and it was on my to-do list, for now i used system reference manual for getting the desired info. Mar 26 21:58:57 knowing which interfaces have compatible equivalents on the two boards at least allows evaluation of which capes _could_ be supported on the BBAI, as well as allow designers of new capes to keep BBAI compatibility in mind Mar 26 22:01:01 Although some peripherals are not available to us like we only have one can on BBAi but 2 on BBB. Mar 26 22:01:13 please see this -> https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec Mar 26 22:02:00 I guess almost all of the capes can be made compatible with the BBAi. Mar 26 22:02:06 ah nice you've made such an overview Mar 26 22:03:44 The main reason of defining new aliases is to not get confused when we change the boards. for example spi0 should be referenced to spi2 on BBAI Mar 26 22:04:15 And another reason is obviously compatibility between boards. Mar 26 22:05:45 *one CAN peripheral on BBAi but 2 on BBB. Mar 26 22:06:13 there is a hw alternative to this Mar 26 22:06:28 you could have an adapter cape Mar 26 22:07:46 I would like to note this too. Mar 26 22:07:59 ds2: ehm, I fail to see how that would fix any problem being discussed... they've already tried to choose pin assignment in a way that maximizes compatibility Mar 26 22:08:01 The adc on the AI has a seperate chip. Mar 26 22:08:21 It is not in the am5729. Mar 26 22:08:34 zmatt: small FPGA cape that routes pins around Mar 26 22:08:45 the FPGA is just a big switch matrix Mar 26 22:10:47 give the FPGA a small i2c interface to select things and/or eeprom emulation Mar 26 22:11:54 well, if you think that's useful for anyone and a good idea to make, go right ahead Mar 26 22:12:23 (it probably is for *someone*) Mar 26 22:12:32 that's been on my plans for a long time... got other projects backlog in front of it Mar 26 22:13:02 it started as an idea for a universal voltage level xlator Mar 26 22:13:05 ds2: that would cost more to customer and we have to keep different set of software for both. That defeats the whole compatibility idea right? Mar 26 22:13:27 lorforlinux: yeah this isn't a suggestion that's of any relevance to your project Mar 26 22:13:29 lorforlinux:maybe on the first and not necessarily for the 2nd Mar 26 22:14:26 can we use config-pin tool on BeagleBoneAI? Mar 26 22:14:27 ds2: from a hardware pov the bbai has already been designed with pin-compatibility in mind, right now the issue is mainly software Mar 26 22:15:01 lorforlinux: config-pin is a simple shell script to view/change the state of bone-pinmux-helper devices Mar 26 22:15:11 zmatt: SW can't do anything about hw not being at certain places... last I look it was a best effort fit Mar 26 22:16:04 ds2: correct, but working around that for capes that need it is a matter completely separate from lorforlinux's gsoc project Mar 26 22:16:58 zmatt: GSoC is still in the application state and can be tweaked up til the app is finalized Mar 26 22:17:33 ds2: what you're suggesting is unrelated to it and completely out of scope. it's also not even a software project Mar 26 22:17:57 if you want to make it, noone is stopping you Mar 26 22:18:21 anyway, time to munch some food Mar 26 22:18:48 zmatt: I just wanted to know if config-pin can be used in a stable manner on BBAI as it used is to Set to , configuring pin multiplexing and optionally configuring the gpio. Mar 26 22:20:24 zmatt: see yaa soon, i will go for a break too! Mar 26 22:21:04 22:44 <@zmatt> right now the only way to do glitch-free pinmux is by changing hardcoded pinmux tables that are compiled into u-boot Mar 26 22:21:35 you're asking something that's already been answered Mar 26 22:22:27 sorry, my bad. Mar 26 22:24:27 it _might_ be possible to make DT-based pinmux (including by cape overlays) glitchless in the future, but runtime pinmux (e.g. by bone-pinmux-helper) will always suffer from this issue. that doesn't mean you can never use it, just that you need to be aware of the potential of glitches (which unfortunately haven't really been characterized) Mar 26 22:29:01 zmatt: I am still at the learning stage, reading books on beaglebone. I will catch up with you when i get the whole picture :) Mar 26 22:30:12 I happy to know that it might be possible to use bone-pinmux-helper in future. Mar 26 22:35:06 lorforlinux: I don't think you actually read what I just said Mar 26 22:35:31 "runtime pinmux (e.g. by bone-pinmux-helper) will always suffer from this issue" Mar 26 22:36:09 if you don't mind the glitches then you don't need to wait for the future, you can use it today Mar 26 22:36:45 if you do mind the glitches then you will not be able to use bone-pinmux-helper, ever. Mar 26 22:38:35 zmatt: i read what you wrote, thanks for making it more clear now. Mar 26 22:44:27 Hey...what characters are these so-called glitches entailing? Mar 26 22:44:42 Like...for instance? Mar 26 22:45:07 I guess i just missed the real meaning of your words because i interpreted that is might be possible and possibilities give hope and hopes keep you motivated and you work towards your goal and one of my goal is to get the pin muxing glitchless on am572x. Mar 26 22:45:28 Right! Mar 26 22:45:35 I would love that a bunch. Love! Mar 26 22:46:33 lorforlinux: btw to clarify what bone-pinmux-helper does: any device can have one or more pinmux states declared in DT. most commonly only the "default" state is used, but you can also define pinmux for the "init" state (used prior to device initialization) and "sleep" state (used during suspend). although most drivers don't concern themselves with pinmux, they can request specific pinmux state if ... Mar 26 22:46:33 set_: when you do dynamic pin muxing on AM57xx SoC the GPIOs will show glitching. Mar 26 22:46:39 ...they want to. bone-pinmux-helper is simply a trivial driver for virtual platform devices (i.e. not corresponding to any physical hardware) that allows userspace to query and change the pinmux state for that device Mar 26 22:46:41 Oh. Mar 26 22:47:20 Nice. Mar 26 22:47:37 at least _may_ show glitching. nothing is known about the nature of the glitches or the exact conditions that might trigger them, except for that it may be triggered by changes in pinmux config and iodelay config Mar 26 22:49:12 I've been meaning to see if I can hook my bbai up to our scope at the office and see these glitches Mar 26 22:49:34 So, DT need to be typed up for use w/ the AI. Okay. Mar 26 22:49:47 right now DT-based pinmux configuration has exactly the same problem Mar 26 22:49:53 No! Mar 26 22:50:04 Oh. I got what you two were discussing. Mar 26 22:50:17 Right now but not in the future (hopefully). Mar 26 22:50:24 Got it. Mar 26 22:51:11 I guess the best thing is to load the required configuration for capes and all that during boot only and using the gpios on default state OR whatever state chosen. Mar 26 22:53:20 zmatt: let me know what you find on the scpe, i am very curious to know more about the glitching. Mar 26 22:53:32 * Scope Mar 26 22:56:13 You guys are making a Cape for the AI or something along those lines? Mar 26 22:56:47 Hi zmatt, sorry probably a too simple question: why r30.t15 corresponds to P8.11. Preferably if you can point me to https://elinux.org/images/d/da/Am335xPruReferenceGuide.pdf Mar 26 22:57:40 Is so, nice! Mar 26 22:58:08 set_: I am participating in GSoC this year for "Cape compatibility between BBB and BBAI" project and for that pin muxing is somewhat a required thing. Mar 26 22:58:21 dreamhiker: you're not going to find anything about the BBB expansion header in generic AM335x documentation Mar 26 22:58:36 but there is plenty of documentation for the BBB expansion headers Mar 26 22:59:41 where do I red about pru registers if not there? Mar 26 22:59:45 read Mar 26 23:00:17 in my pins spreadsheet https://goo.gl/Jkcg0w the P9 and P8 tabs give an overview of the expansion headers including pru modes available, and conversely the "PRU" tab gives an overview of the PRU pins of the AM335x including where you can find them on the BBB expansion headers Mar 26 23:00:38 dreamhiker: r31 itself should be documented in there, and the pru gpio in general Mar 26 23:01:49 sections 5.2.2.1 and 5.2.2.3.1 Mar 26 23:02:35 Oh. Mar 26 23:02:40 loforlinux: Nice. Mar 26 23:03:25 GSoC sounds like a neat thing. I hope you do well. Mar 26 23:04:21 set_: thanks buddy :) Mar 26 23:04:49 You are welcome. I could use you too. I always like to figure out what is wrong w/ what others have accomplished. Mar 26 23:05:02 Cynical! Mar 26 23:05:31 I am a leech, sort of. Mar 26 23:05:42 dreamhiker: the short summary is that each of the two pru cores has 16 direct outputs from r30 bits 0-15 and 17 direct inputs to r31 bits 0-16. for a few of these there are also multiple pinmux options. the PRU tab of aforementioned spreadsheet is the best concise overview of PRU pinmux options I'm aware of Mar 26 23:06:44 lorforlinux: Are you going to figure out how to rewire a medium in b/t the Capes and the AI? Mar 26 23:07:15 set_: no Mar 26 23:07:19 Oh. Mar 26 23:07:22 Okay. Mar 26 23:07:53 Hmm. Oh, that is what ds2 was suggesting. Mar 26 23:07:57 Okay. Mar 26 23:08:06 dt! Mar 26 23:09:20 @se_: as a member of BeagleBone community how do you think the project will help you? you can find the proposal for the poject here https://elinux.org/BeagleBoard/GSoC/2020Proposal/DeepakKhatri Mar 26 23:09:38 Let me get deeper to your spreadsheet. Meanwhile, Is this a right way to assert P8.11? Mar 26 23:09:41 SET r30.t15 // Assert P8.11 Mar 26 23:10:25 Okay. Off to look. Mar 26 23:10:29 I will reply once I read it. Mar 26 23:11:01 @se Mar 26 23:11:14 dreamhiker: if the code is running on pru core0 and P8.11 has been configured to pruout mode then yes Mar 26 23:11:16 set_: sure thing :) Mar 26 23:13:48 Just checking to make sure. The code works. BTW, I have created an excel of PRU asm commands if needed (chet sheet) Mar 26 23:13:53 cheat Mar 26 23:16:49 lorforlinux: Me, personally, would find this very interesting. I love add-ons, Capes, sensors, and actuators. Making a Upward Working Cape would be successful for many people looking to use the AI. Now, easy? I do not know. Mar 26 23:17:11 It is like upward mobility in life. Instead of making things updated, one makes the old work w/ the new. Mar 26 23:17:16 That is success. Mar 26 23:17:37 Now, I am only on your milestones right now. Mar 26 23:17:50 I have to finish it before giving a complete idea. Mar 26 23:19:16 set_: I have to re-adjust the milestones a little-bit, my proposal will take 2 more days to be finish. I am working on Required Hardware part and some other things :) Mar 26 23:19:56 Would your source change the hexidecimal alpha-numeric characters to adjust the differences in labeling? Mar 26 23:20:12 If that makes sense. Mar 26 23:21:16 I have not read #8, #9, and #10 yet either. Mar 26 23:21:22 I need to check those out. Mar 26 23:24:16 zmatt, looking at your PRU tab I do see Out-15, but not mentioning of R30. What do i do wrong? Mar 26 23:25:31 00:05 <@zmatt> dreamhiker: the short summary is that each of the two pru cores has 16 direct outputs from r30 bits 0-15 and 17 direct inputs to r31 bits 0-16 Mar 26 23:26:16 i.e. pru 0 out 15 is controlled by bit 15 of R30 of pru 0 Mar 26 23:29:58 @set_: I just wanted to know how it would help you and i think you have explained it very well. Would it be okay if i quote you on my proposal under Benefit section? Mar 26 23:36:40 lorforlinux: I can probably say something better than that if given time. I just read #8, #9, and #10 on the pull requests. Mar 26 23:36:53 Neat stuff, sir. Mar 26 23:37:15 May I please come up w/ a formal statement? Mar 26 23:39:37 set_: yes please take your time and buddy you don't have to call me sir. Mar 26 23:41:55 lorforlinux: Are you addressing the labeling issue between the two, separate boards (am335x and the am5729)? Mar 26 23:43:18 set_: what do you mean by labeling? Mar 26 23:43:35 Sorry. Mar 26 23:43:58 zmatt: what Mar 26 23:45:02 I am trying to comprehend what it is that you are doing. So, are you making the DT overlays available and all while labeling the am335x pin muxing to the AI w/ the am5729 pin muxing? Mar 26 23:46:21 set_: pin muxing seems unlikely but pin naming and other things for making the boards compatible yeah definitely. Mar 26 23:46:29 zmat, thank you for your spreadsheet. It reminds me the Mendel Elements Table :) Mar 26 23:48:41 Okay. Mar 26 23:49:16 So, would the the Capes work w/ the AI b/c of your research? Mar 26 23:49:23 and work. Mar 26 23:49:58 I see some blanks. May I ask you What does PRU0 R30.t10 controls? Mar 26 23:50:02 Sorry. I am a simpleton right now for some reason. Mar 26 23:51:31 set_: yes Mar 26 23:52:03 Nice. Mar 26 23:53:09 yupp Mar 26 23:53:48 lorforlinux: I say do it and do it well. That is awesome research. Mar 26 23:55:11 off topic but some may find this a fun read http://www.righto.com/2020/03/inside-titan-missile-guidance-computer.html Mar 26 23:56:10 thanks set_, I think what you said above is enough for me to include in proposal. Mar 26 23:56:26 lorforlinux: I cannot wait. Quote whatever whenever from me. I have some funny, anecdotle stuff that I say but sometimes if you pay close attention, I might say something out of the ordinary for me. Mar 26 23:56:31 Nice. Mar 26 23:56:49 Good luck. Mar 26 23:57:06 thanks for your wishes set_ Mar 26 23:57:36 You are welcome. I have some capes and I would like them to work w/ new hardware. Mar 26 23:58:05 GenTooMan: that post is gold man. Mar 26 23:58:28 set_: sure :) Mar 26 23:59:21 up, up, and otay! Mar 26 23:59:23 bbl Mar 27 00:03:52 hmm correcting the issue with the pinmux and the driver to change the pinmux is noble. I'm now curious (dang it zmatt you made me curious). Mar 27 00:30:39 GenTooMan: hmm? Mar 27 01:11:35 New hardware = AI! Mar 27 01:26:08 you have AI generated hardware? Mar 27 01:26:15 first steps toward skynet? Mar 27 01:28:51 Skynet and bots? Mar 27 01:29:16 I was just commenting on another thing from earlier. Mar 27 01:40:02 Well, what would have been the Maker Faire here has now been cancelled. Now, I can get back to projects! Boo and yay! Mar 27 01:48:39 4.19.x works on the AI now. I wonder if I have the rt image still. Off to check! Mar 27 01:50:16 NOpe. Dang. Mar 27 01:50:56 has the broadcom wifi driver been fixed yet? otherwise installing an rt kernel will presumably still result in a broken system on the bbai Mar 27 01:51:11 I am not sure. I can check in a bit. Mar 27 01:51:30 what do you need an rt kernel for anyway? Mar 27 01:51:58 I forgot but I wanted it for something a while back. I will most likely remember when you are not paying attention. Mar 27 01:52:05 I will try to get your attention soon when I remember. Mar 27 01:52:13 But... Mar 27 01:52:42 I may have been just testing. I was going to hook up an entire motor set up and some other things to pursue old source on the BBAI. Mar 27 01:53:09 w/out muxing...I was just going to set up what is available. Mar 27 02:00:54 Nice man...I see you guys put the 4.19.x kernel to use w/ the ti-tidl package. Mar 27 02:28:42 I just caught something while upating items and installing. apt install xfce4 caused a network connection error. I rebooted. More to come. Mar 27 02:35:44 The reboot fixed whatever happened. No issue. **** ENDING LOGGING AT Fri Mar 27 02:59:57 2020