07:31 <Guest5> First of all, good day everyone. We use your Black model card in a medical-based device. We use MEAN WELL adapters with model number GSM60A05-P1J in our devices. this adapter causes the beaglebone to turn back on after being turned off. But when we tried it with cheaper and poor quality adapters, we saw that we did not encounter such a problem. We

07:31 <Guest5> could not find any technical solution to the situation. Thanks in advance for your help.

07:32 <zmatt> I've heard of people having that problem with some adapters when the beaglebone is simultaneously also powered via usb (in addition to via the 5V barrel jack)

07:32 <zmatt> is the device also connected via usb in your case?

07:35 <Guest5> Yes there is a USB connection but it is not supplying power to the device. Also we've encountered this issue when there is no USB connection

07:36 <zmatt> how do you know it's not supplying power? when both power sources are available the BBB will switch between them automatically based on voltage, unless you explicitly override the PMIC's configuration

07:36 <zmatt> though it's interesting that you're also seeing the issue without usb

07:40 <zmatt> in that case, I've never heard of a similar problem before. I have no idea what could be causing that, my suggestion would be to use a scope to examine what's happening on the 5V input (which you can measure on P9.05) during the moment of switching off, e.g. using falling edge on SYS_5V (P9.07) or the 3.3V supply (P9.03) as trigger

07:41 <zmatt> when you say "turn back on after being turned off" I assume you mean that when it shuts down by software request, it effectively just performs a reboot?

07:45 <Guest5> The hardware button of the device (not BBB's) sends the command sudo poweroff.

07:46 <Guest5> But the same thing happens when we use the switch on the BBB to turn it off

07:46 <zmatt> those trigger the same thing, they're both software requests

07:46 <Guest5> I know it is not supplying power because a usb hub is connected to able to connect several components. Even if I am mistaken, like IThis not a constant problem, however it is a reoccurring problem. We see this on roughly 40% of our devices.

07:48 <Guest5> Even if I am mistaken, like I've said we've tried it without connecting anything except a 5V power supply (barrel jack)

07:50 <zmatt> that's really strange... I can kinda sort of imagine how it might happen if both power sources are connected (not really, but the tps65217 pmic is kinda stupid so it makes some amount of sense) but I have trouble imagining how it could happen when powered just from the barrel jack... very odd indeed

07:55 <zmatt> if you can reproduce it then like I said, hopefully an investigation with a scope would reveal what's going on on the 5V supply line during poweroff

07:57 <zmatt> maybe the sudden loss of load causes the output voltage of the 5V supply to briefly swing up to the overvoltage detection limit (typ 6V, min 5.8V)

07:58 <zmatt> in which case the problem could probably be solved by connecting a resistor across the power supply output (e.g. between P9.05 and P9.01) to create some load even when the beaglebone is switched off

07:59 <zmatt> although that's not very elegant

07:59 <zmatt> this is purely a guess though, there's no way to begin debugging this without a scope trace

08:01 <zmatt> there's 10 μF of capacitance on the 5V input though, so I'd normally expect that to prevent a large output transient of the supply caused by the sudden loss of load

08:01 <zmatt> but dunno, it's all I can think of

16:15 <Konsgn> Has anyone worked with fpga programming via spi port from the linux user space or kernel?

20:19 <zmatt> Konsgn: regarding your earlier dmtimer question: I assume you mean on one of the timer4-7 pins? dmtimer can indeed be configured into pwm mode, hence in particular can output a clock (with period and duty cycle in units of 1/24th microsecond)

20:20 <zmatt> the kernel has an pwm-omap-dmtimer driver for that

20:21 <zmatt> if you need it to be a clock device for the kernel, there's the clk-pwm driver for that

20:24 <zmatt> Konsgn: as for "fpga programming via spi" that question seems both too specific and too vague... it's too specific in the sense that if you have documentation on what transfers to perform then all you need to know is how to perform spi communication in general, while if you really want to ask about programming an fpga you'd need to specify which exact one since I do not think there's any kind of ...

20:24 <zmatt> ...standard regarding how fpgas are programmed

20:39 <Konsgn> true that, I was looking into the xilinx_spi_probe section of relevant drivers and this doc: https://github.com/beagleboard/linux/blob/master/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt

20:40 <Konsgn> was thinking of trying to use dmtimer7 to output a clock and pll-synthesize a master clock in the xilinx from that.

20:54 <zmatt> there's also clkout1 on P9.41

20:54 <zmatt> or clkout2, whatever it's called

20:57 <Konsgn> clkout2 is only for 32khz out though right?

20:57 <zmatt> nope

21:02 <zmatt> Konsgn: https://pastebin.com/raw/6hfvetBS

21:03 <Konsgn> interesting. I could use that then.

21:03 <zmatt> didn't immediately find a maximum permitted frequency in the datasheet... I'd not feel confident about outputting a 400 MHz clock without a postdivider ;)

21:03 <zmatt> (especially not via the beaglebone's headers anyway)

21:04 <zmatt> P9.41 also has the downside that it connects to two SoC pins, which may reduce signal integrity (depending on how close to the SoC they're tied together)

21:05 <Konsgn> yea, thinking 100mhz

21:06 <zmatt> the clock is &clkout2_ck

21:08 <zmatt> hmm, DT declares the divider with max-div=<8> but based on the TRM that should be max-div=<7>

21:08 <zmatt> (TRM says 0..6=/1../7 and 7=reserved)

21:21 <Konsgn> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/Bindings/clock/ti/gate.txt last example

21:21 <Konsgn> and modify the clocks entry?

21:22 <zmatt> no

21:23 <zmatt> generally speaking you should never modify a clocks property since it is a declaration of how the hardware is structured

21:24 <Konsgn> hmmm.

21:26 <zmatt> there's kernel APIs to change clocks or you can use assigned-clocks to do so in DT

21:29 <zmatt> something like this I think: https://pastebin.com/raw/ByHVrwMk

21:30 <zmatt> this it asking the parent of &sysclkout_pre_ck (the mux) to be set to &l3_gclk, and the rate of &clkout2_div_ck (the divider after the mux) to be set to 100 MHz

21:30 <zmatt> *this is

21:30 <Konsgn> goes in root node?

21:30 <zmatt> normally goes in the device node for which these clocks should be setup

21:31 <zmatt> putting them in the root sounds like a bad idea

21:31 <Konsgn> so for a clockout pin it could just go into a &gpio node or something?

21:31 <zmatt> what does it have to do with gpio?

21:32 <zmatt> if your fpga has a node, that would be the logical place

21:32 <Konsgn> to get clockout on a gpio pin

21:32 <Konsgn> ahhh gotcha

21:32 <zmatt> there's no such thing as a "gpio pin", gpio is a particular function of a pin, one that is mutually exclusive with clkout

21:32 <Konsgn> okay, i see what you mean. too used to looking at all pins as gpio

21:32 <Konsgn> Thank you

21:33 <zmatt> your fpga node should also have clocks = <&clkout2_ck>; and the driver should request and enable it

21:36 <zmatt> e.g. devm_clk_get() + clk_prepare_enable()

21:37 <zmatt> and of course have a pinmux declaration for the clkout pin

21:39 <Konsgn> bah, so a driver needs to be compiled for utilizing fpgamanager? i was hoping to use fpga-region to declare the bitstream needed to send and add the clock settings to it.

21:41 <zmatt> I don't know how fpgas are handled by linux, is there no support for declaring a clock?

21:43 <zmatt> last time I found myself in need of making linux enable a clock without really having any good way to request it, I cheated: https://github.com/mvduin/overlay-utils/blob/master/uio/ehrpwm0.dtsi#L19-L23

21:43 <Konsgn> no clue, there doesn' seem to be a lot of info on it. at least one project i found(kiwisdr) just uses a user space program to do the programming/comm

21:44 <Konsgn> hahah

21:47 <zmatt> various individual drivers in drivers/fpga do request clocks... specifically xilinx-pr-decoupler.c, altera-hps2fpga.c, socfpga-a10.c, and zynq-fpga.c

21:49 <zmatt> someone tried to submit a userspace clock consumer device, but got rejected

21:58 <Konsgn> how come?

21:59 <Konsgn> something like passing through to pinout seems like it could be useful

22:01 <zmatt> because of kernel devs thinking such things should be controlled by the kernel and not userspace

22:04 <zmatt> same reason kernel documentation says the userspace gpio interface is "intended for one-off deployments" used in "specialized equipment that is not produced by the numbers, requiring operators to have a deep knowledge of the equipment"