**** BEGIN LOGGING AT Mon Aug 31 19:23:55 2020 Aug 31 19:24:29 this has nothing to do with power management (which is handled by prcm), the purpose is to have a way to ungate multiple pwm clocks at once to allow them to start at exactly the same time (hence run perfectly in sync) Aug 31 19:25:38 which is a point linux missed completely since they enable them via separate clock nodes, completely defeating the point Aug 31 19:26:38 the problem is that they're not enabled by default, so the tricky bit is to ensure these bits get set, either when the pwm module is active or unconditionally Aug 31 19:26:59 so is the example I am following still bad coding? Aug 31 19:27:09 your example doesn't deal with it at all in any way Aug 31 19:27:16 it just assumes they're somehow enabled Aug 31 19:27:20 lol Aug 31 19:27:22 (which they're not) Aug 31 19:27:58 now it is possible to set these from userspace, though it requires /dev/mem (hence root access) and a weird disgusting hack Aug 31 19:28:12 yeah I did not like having to run under sudo Aug 31 19:28:37 it could be done by a small separate util run at boot, but still I'd prefer a better solution Aug 31 19:28:40 lemme think for a bit more Aug 31 19:28:44 ok Aug 31 19:34:52 I have an idea Aug 31 19:40:28 "Don't worry, Charlie. I've got an angle." - Captain Stern Aug 31 19:50:05 I mean, this works I guess... but I'm not proud of it :P Aug 31 19:50:33 since it seems impossible to convince the kernel to enable the tbclk... Aug 31 19:50:39 &ehrpwm1_tbclk { ti,set-bit-to-disable; }; // XXX DISGUSTING HACK Aug 31 19:50:55 might as well make it think the bit has inverted meaning Aug 31 22:13:16 my kernel is 4.19.94-ti-r42 Aug 31 22:13:22 is there a problem with this one Aug 31 22:37:59 no? Aug 31 22:38:48 MattB000ne: I made a working overlay for ehrpwm via uio btw: https://github.com/mvduin/overlay-utils/blob/master/uio-pwm1.dtsi Aug 31 22:45:53 ok cool Aug 31 22:51:46 and pushed preliminary definitions to py-uio Aug 31 22:52:16 great I will check it out Aug 31 22:52:22 how did you work around that clocks issue Aug 31 22:52:34 as in, this is the full extent of the testing I've done: https://pastebin.com/5wmbmx5J :P Aug 31 22:53:04 https://github.com/mvduin/overlay-utils/blob/master/uio-pwm1.dtsi#L53-L57 that's how **** BEGIN LOGGING AT Mon Aug 31 23:04:12 2020 Aug 31 23:07:33 i love the yes this is disgusting comments Aug 31 23:07:45 in a perfect world is this a hardware change Aug 31 23:07:47 ? Aug 31 23:08:23 I mean, it would have been nice if they were enabled by default in hardware so linux could have ignored it entirely Aug 31 23:09:16 but the fact it's so hard to get the kernel to use the clocks is because in kernel 4.19 a lot of information (such as which clocks are used by which modules) is still hardcoded in the kernel instead of being in the DT Aug 31 23:09:40 i see Aug 31 23:10:18 there are a whole bunch of ways to deal with this, I just used the solution that was the least effort Aug 31 23:12:18 works for me Aug 31 23:12:32 can I switch to pwm0 and use P9_21 and P9_22 Aug 31 23:12:38 will that break anything Aug 31 23:13:09 i just swtiched the pins and mode as well as the symlink line Aug 31 23:13:17 uio/owmss0/module Aug 31 23:13:39 i dont have 14 and 16 open because of the touch screen Aug 31 23:13:47 there's more changes required Aug 31 23:14:20 the registers right? Aug 31 23:16:36 so I am also going to switch the ranges to <0x48300000 0x48302000 0x1000> Aug 31 23:17:02 actually <0x48300000 0x48300000 0x1000> Aug 31 23:17:07 replace all 48302 by 48300 Aug 31 23:17:19 was close Aug 31 23:17:21 ok Aug 31 23:17:54 and interrupts <86>, <58> Aug 31 23:18:21 actually listing the second one is nonsense, only the first one is used Aug 31 23:18:43 if you get would the short cuts vim is pretty potent Aug 31 23:18:46 good* Aug 31 23:19:01 (and you're not going to use the interrupt anyway so you could also just omit them) Sep 01 00:58:43 Im trying to build a beaglebone image through the omap-image builder, I have built the image. But when I try to write the image into a SD card for testing. I am getting a warning Missing partition table. I tried to ignore the warning but the beaglebone is not booting with the newly built image. Can you help me fix this? Sep 01 01:00:45 I've never tried the image builder Sep 01 01:03:49 does it maybe produce a filesystem image rather than a card image? Sep 01 01:03:58 zmatt: is failing to disable wkup cm:clk a real problem Sep 01 01:04:55 MattB000ne: no... the traceback is annoying but it appears harmless... I kinda understand why it's happening although I don't really get yet why it's only happening to uio-pruss on kernel 4.19 (and not to uio-pruss on 4.14 nor to remoteproc-pru on 4.19) Sep 01 01:05:08 ok Sep 01 01:07:09 ok I do not have anything in /dev/uio other than pruss Sep 01 01:07:22 trying to do the same commands in the pastebing Sep 01 01:07:34 pastebin you sent of your testing Sep 01 01:07:49 oh yeah you need to install the etc/modprobe.d/uio.conf file included with py-uio Sep 01 01:08:00 ok Sep 01 01:08:07 I initially forgot that step too Sep 01 01:19:28 copied the uio.conf to the corresponding spot in /etc Sep 01 01:19:47 but I am still do not have anything in /dev/uio Sep 01 01:19:50 other than pruss Sep 01 01:20:19 did you reboot? Sep 01 01:20:40 "to the corresponding spot in /etc" as in, to /etc/modprobe.d/ ? Sep 01 01:20:45 yes Sep 01 01:20:55 and yes Sep 01 01:21:10 what does your overlay look like? Sep 01 01:22:40 https://pastebin.com/WBzufeTX Sep 01 01:23:05 ehh you still have a whole bunch of 1s that need to be 0s Sep 01 01:23:38 replace all pwmss1 by pwmss0 and ehrpwm1 by ehrpwm0 Sep 01 01:23:45 crap Sep 01 01:23:48 ok I see them now Sep 01 01:24:24 I'm actually surprised your system booted at all Sep 01 01:24:48 given the dangling reference in your overlay Sep 01 01:25:41 oh how did I accidently manage to use the old pin macros Sep 01 01:27:07 whats a dangling reference Sep 01 01:27:19 the inconsistency of the pwm1 vs pwm0 Sep 01 01:27:21 ? Sep 01 01:28:34 your overlay referenced &ehrpwm0_pins which doesn't exist (the overlay declared a node labeled "ehrpwm1_pins" instead) Sep 01 01:36:40 ok now it works Sep 01 01:36:45 so I can reproduce your test Sep 01 01:38:31 so I can do pwmss0.enable = 1 right Sep 01 01:38:38 or do I need to set everything first Sep 01 01:38:56 there's nothing of interest to you in the subsystem other than the .pwm Sep 01 01:40:42 and getting that to work would require examining both my initial draft of the uio.ti.epwm.EPwm class and probably the TRM Sep 01 01:41:10 right I see all the bits Sep 01 01:41:19 I need to read more to see what to set everything to Sep 01 01:42:07 so I need to create an instance with something like ehrpwm0= pwmss0.EPWm Sep 01 01:42:13 then assign the fields properly Sep 01 01:42:34 no, ehrpwm0 = Pwmss("/dev/uio/pwmss0").pwm Sep 01 01:43:14 or just call it epwm0 since nobody uses the "hr" part and the registers thereof also aren't even declared yet in my class :P Sep 01 01:44:07 ok and from there set the bits approrpirately to get the behavior I want. Using the TRM to tell me what bits to set Sep 01 01:50:23 I should change some definitions to be saner and get rid of the inconsistencies created by the unused HR stuff Sep 01 01:52:26 will read the TRM tonight and attack this tomorrow Sep 01 01:52:40 I'll probably push an update in a bit Sep 01 01:53:05 ok I will check back in a bit going to go eat **** ENDING LOGGING AT Tue Sep 01 02:59:57 2020