06:59 <jkridner> sneak peak: https://beaglebone.ai/64 --- order pages should go live some time in the next several hours.

08:18 <set_> nice!

14:40 <calrama> zmatt: Hey, just wanted to let you know that I finally got the timer pwm output on bbai working. For reference, here are the complete needed steps:

14:40 <calrama> 1. Patch the ( 4.14-ti ) kernel ( https://lore.kernel.org/all/20180716071323.GB23110@amd/ )

14:40 <calrama> 2. Patch beagleboard-devicetrees' `src/arm/dra7.dtsi`, because it's missing all the necessary `ti,timer-pwm;` compatibility lines (omap-dmtimer-pwm won't load otherwise)

14:40 <calrama> 3. Add the pwm device tree node.

14:40 <calrama> (See https://pastebin.com/raw/iEnYXRd6 for e.g. timer14)

14:40 <calrama> 4. "Backport" (just copy it) `src/am572x-bone-common-univ.dtsi` from kernel 4.19, which allows configuring pinmuxing via e.g. `/sys/devices/platform/44000000.ocp/44000000.ocp\:P8_09_pinmux/state` (for timer14; other timer output for e.g. 15 and 16 are missing from univ and they need to be added as per the am5729 TRM, but that's straight forward)

14:40 <calrama> 5. Boot with custom kernel and custom dtb

14:40 <calrama> 6. Get a slight panic attack because the pwm isn't actually enabled by default; then export, configure, and enable it as per https://develop.phytec.com/how-to-articles/how-to-use-pwm-in-linux (the actual path should be something like `/sys/class/pwm/pwmchip0/pwm-0:0` after exporting)

14:40 <calrama> 7. connect your osci and be happy

16:10 <calrama> Unfortunately, the maximum input clock rate for the pwm timer seems to be 20 MHz, which is the `output` clock rate I need, so it doesn't seem suitable to me. It seems I'll have to indeed go the PRU route in order to route a 20 MHz clock outside of the bbai.

16:11 <calrama> the highest the pwm driver (sensibly) lets itself be configured is ~12 MHz.

22:20 <zmatt> calrama: if you're making a custom dtb anyway, why did you port cape-universal instead of just giving the devices you use the pinmux they need? (i.e. the way pinmux in DT works normally)

22:29 <calrama> zmatt: Because when I started I had zero idea on how that all worked and figured stealing an existing solution for a newer kernel to be less time intensive.

22:29 <calrama> *from a newer kernel

22:31 <calrama> I'll eventually remove the backport eventually and switch to doing everything in a DT, like you said. But for now there are other priority tasks^^

22:42 <zmatt> calrama: fair enough :)

22:45 <zmatt> calrama: on the AM572x you're officially actually supposed to setup pinmux in u-boot because of a chip erratum, but that's extremely tedious (and afaik so far no board has spontaneously combusted as a result of ignoring TI's instructions on this issue)

22:55 <zmatt> ( https://www.ti.com/lit/er/sprz429m/sprz429m.pdf page 60 if you're curious). The suggested workaround, putting the IO into isolation mode while configuring pinmux, is done in u-boot SPL before the ddr3 memory controller is enabled since I/O isolation mode affects its I/O as well)

23:07 <zmatt> erratum i933 (page 91) is problematic as well for dynamic pinmux config, since some to get the exact right signal timing some pin functions may need specific iodelay settings

23:10 <zmatt> (iodelay is exactly what it sounds like: every configurable I/O on the AM572x a programmable delay line to allow signal timing to be tweaked in steps of (iirc) a few dozen picoseconds.... or to be more precise, each I/O has _three_ (independently) programmable delay lines: one for input, one for output, one for output-enable)

23:11 <zmatt> jkridner: nice!

23:12 <zmatt> jkridner: the digikey listing shows an image of the bbai rather than the ai64