I had the same issue driving RBG Leds.
They were starting turned on full force since the PWM was driving high on boot.
Changing the polarity worked for me.
Is it possible the order of overlays is undoing your changes to bone_pwm_P8_13?
Instead of:
It’s not a kernel driver, I believe it’s the processor default mode. You can check the processor datasheet:
If you want to change it earlier than linux, you need to set the pin in uboot (as far as I can understand). You can check the list because I know that I have already read something about change default IO in BBB. Or something about u-boot and gpio, like this: Hopefully, this can help a little… Miguel Aveiro
IN short, use external hardware or do something cleaver like Peter G, and reverse polarity. OR have an external “switch” that switches the PWM line off, until you tell it to turn on. simples ?
I’m not sure about that. Jan said before that it’s only driven high after loading the PWM driver, and the processor datasheet shows ball T10 (P8_13) as driven low during/after reset.
Jan, not ideal, but to disable the output sooner you could load the overlay through cape manager, and then write 0 to the run parameter immedately afterwards. But I still think the correct approach is to look at the devcetree/driver code and see why those parameters are having no affect…
I had another look at this, was able to replicate what you are seeing, and think I know what's going on..
The part-number 'bone_pwm_P8_13' is already included in the kernel build. I'm not really sure of the mechanics, but when doing a build from the git repository, all the .dts files in the /firmware/capes folder get compiled to individual .dtbo files, and from there into object files, and then combined into a single built-in.o file.
The end result of this appears to be that putting an overlay file for one of these built-in part-numbers into /lib/firmware doesn't achieve anything, it just doesn't get read (even if you increment the version).
Anyway, it's an easy fix - once you know what's going on!! You should just need to change the part-number to something else unique (and the file name to suit), and then the options can be set in your overlay as you'd expect..
Thank you for your valuable input.
I will try it soon and let you know.
The obvious question already is which one will take precedence in loading:
the overlay defined in the kernel or the one handled by the cape manager?
but in /sys/devices/ocp.3/pwm_test_P8_13.16 I have only:
root@beaglebone:/sys/devices/ocp.3/pwm_test_P8_13.16# ls
modalias power subsystem uevent
My bone_pwm_test-00A0.dts and bone_pwm_test-00A0.dtb0 are in /lib/firmware
Do I need to make any changes to them after all (as the renaming only doesn’t work)?