I can’t write to the control module CTL_MOD address @0x4e100664 using PRU0 or the mmap function. The only way I can enable these clocks is by enabling using sysfs /deb/bone/pwm/0-2a&b.
Is their something I can do to my overlay to unlock that address?
I am using Debian 13 with kernel 5.10.168-ti-r83 with cape-universal enabled in the uEvn.txt file.
LINUX-EHRPWM1-2.dts (2.3 KB)
And just looked into the device tree for this. Setting the status to anything other than okay, or ok, and that part is dissabled. Now what worries me is this means the pin mux is also disabled. So may need to put the pin mux elsewhere in the device tree. I’ll try tomorrow on my BBB.
Tried changing status to “reserved” - which is what we are doing. The kernel doesn’t bring up the kernel pwm interface, my code runs - but doesn’t flash the lights. Tomorrow I check if it is missing pin mux, or if I haven’t yet set up everything …
And now checked, with the pwm status set to reserved, and linux doesn’t bring up the pwm, but I still can’t write to CTLMOD. The ti drivers are compiled into my kernel - so I can’t tell if they start anyway and lock the memory.
I’ve also noticed that my writes to the PWM SYSCONFIG registers failed …
I will check discord to see if their is a solution.
I entered the wrong address should be: 0x44e10664
Is their a way to add this to a overlay without crashing the boot process?
&ephrpm0_tbclk { status = “okay” };
Is the location of my overlay “uboot_overlay_addr0 - 7” or elsewhere in the /boot/uEnv.txt relevant?
Crux is uEnv.txt is read and executed by Das UBoot. Uboot became FDT aware many years ago, and grew to have commands to modify the device tree. Just changing a single line in the device tree is more easily done at boot time in uboot.
I describe the approach Here ; and that should still work.
Crux to remember though is uboot is a sensitive beast, if you may just a minor mistake in the uboot scripting, uboot crashes out and doesn’t boot linux. So make changes to uEnv.txt very carefully until you know what you are doing. It may actually be easiest to attach a serial cable to machine uart, then watch uboot coming up - and you can interrupt it, and then type the commands by hand. This way you can try out commands - until you get the syntax right; and then the change more permanent in uEnv.txt.
Oh yes also worth saying you can’t use the alias &ehrpm0_tbclk in uboot (at least I don’t think so), so you’ll have to give the full path of what you want to modify in the device tree.
Also check this post it shows how to do things in the uEnv.txt approach - problem is IIRC is its a functional language that uEnv.txt uses, so you have to define aliases, so expansion gives the comand sequence you want …
So need to trace back ehrpwm0_tbclk → l4ls_gclk →dpll_core_m4_div2_ck → dpll_core_m4_ck (div 2) → dpll_core_x2_ck → dpll_core_ck →sys_clkin_ck
I’m not sure that any of these you can set the status - its just how the clocks are connected, and the clock that eventually leads to ehrpwm0. Guess the question is what do you want to achieve here?
At this point I will just use your solution of using a Linux c++ app that sets the period/duty_cycle then enables EHRPWM0-2. Using my overlay their is no need for exporting since the EHRPWM’s are already exported as /dev/bone/pwm/0-2/a&b.
Trying to member history, didn’t /dev/bone go when the overlays went, back in version 4 of the kernal: Where did the slots file go?
No they didn’t the device trees for 5.10 and 6.18 are using symlinks “bone/xxx”. What I can’t find is any symlinks in the /opt/source folders for “/dev/bone/pwm/xx/xx”. But they do show up for 5.10. Whethre ti boot with Cape Universal Enabled or not using my overlay enableing the 3 EHRPWM’s I get the symlinks. I also get symlinks for eqep as /dev/bone/counter, /dev/bone/ecap, /deb\v/bone/i2c, /dev/bone/pwm, and /dev/bone/uart.
Ah OK - I installed arch on my BBB quite early on - and that lost the various beagle board helpers quite early on as I remember it. So overlays and thing done in uboot, using the standard uboot device tree operations. But sounds familiar - as many people that changed to arch were always asking about where things went.