**** BEGIN LOGGING AT Wed Dec 15 02:59:57 2021 Dec 15 07:31:09 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 Dec 15 07:31:09 could not find any technical solution to the situation. Thanks in advance for your help. Dec 15 07:32:17 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) Dec 15 07:32:55 is the device also connected via usb in your case? Dec 15 07:35:08 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 Dec 15 07:36:19 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 Dec 15 07:36:29 though it's interesting that you're also seeing the issue without usb Dec 15 07:40:10 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 Dec 15 07:41:45 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? Dec 15 07:45:40 The hardware button of the device (not BBB's) sends the command sudo poweroff. Dec 15 07:46:00 But the same thing happens when we use the switch on the BBB to turn it off Dec 15 07:46:32 those trigger the same thing, they're both software requests Dec 15 07:46:45 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. Dec 15 07:48:47 Even if I am mistaken, like I've said we've tried it without connecting anything except a 5V power supply (barrel jack) Dec 15 07:50:17 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 Dec 15 07:55:31 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 Dec 15 07:57:03 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) Dec 15 07:58:39 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 Dec 15 07:59:02 although that's not very elegant Dec 15 07:59:34 this is purely a guess though, there's no way to begin debugging this without a scope trace Dec 15 08:01:27 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 Dec 15 08:01:37 but dunno, it's all I can think of Dec 15 16:15:18 Has anyone worked with fpga programming via spi port from the linux user space or kernel? Dec 15 20:19:40 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) Dec 15 20:20:25 the kernel has an pwm-omap-dmtimer driver for that Dec 15 20:21:30 if you need it to be a clock device for the kernel, there's the clk-pwm driver for that Dec 15 20:24:24 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 ... Dec 15 20:24:31 ...standard regarding how fpgas are programmed Dec 15 20:39:52 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 Dec 15 20:40:36 was thinking of trying to use dmtimer7 to output a clock and pll-synthesize a master clock in the xilinx from that. Dec 15 20:54:11 there's also clkout1 on P9.41 Dec 15 20:54:52 or clkout2, whatever it's called Dec 15 20:57:17 clkout2 is only for 32khz out though right? Dec 15 20:57:32 nope Dec 15 21:02:06 Konsgn: https://pastebin.com/raw/6hfvetBS Dec 15 21:03:06 interesting. I could use that then. Dec 15 21:03:10 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 ;) Dec 15 21:03:35 (especially not via the beaglebone's headers anyway) Dec 15 21:04:50 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) Dec 15 21:04:59 yea, thinking 100mhz Dec 15 21:06:38 the clock is &clkout2_ck Dec 15 21:08:17 hmm, DT declares the divider with max-div=<8> but based on the TRM that should be max-div=<7> Dec 15 21:08:39 (TRM says 0..6=/1../7 and 7=reserved) Dec 15 21:21:18 https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/Bindings/clock/ti/gate.txt last example Dec 15 21:21:33 and modify the clocks entry? Dec 15 21:22:06 no Dec 15 21:23:41 generally speaking you should never modify a clocks property since it is a declaration of how the hardware is structured Dec 15 21:24:00 hmmm. Dec 15 21:26:33 there's kernel APIs to change clocks or you can use assigned-clocks to do so in DT Dec 15 21:29:29 something like this I think: https://pastebin.com/raw/ByHVrwMk Dec 15 21:30:08 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 Dec 15 21:30:12 *this is Dec 15 21:30:32 goes in root node? Dec 15 21:30:54 normally goes in the device node for which these clocks should be setup Dec 15 21:31:24 putting them in the root sounds like a bad idea Dec 15 21:31:37 so for a clockout pin it could just go into a &gpio node or something? Dec 15 21:31:49 what does it have to do with gpio? Dec 15 21:32:01 if your fpga has a node, that would be the logical place Dec 15 21:32:02 to get clockout on a gpio pin Dec 15 21:32:13 ahhh gotcha Dec 15 21:32:20 there's no such thing as a "gpio pin", gpio is a particular function of a pin, one that is mutually exclusive with clkout Dec 15 21:32:46 okay, i see what you mean. too used to looking at all pins as gpio Dec 15 21:32:54 Thank you Dec 15 21:33:53 your fpga node should also have clocks = <&clkout2_ck>; and the driver should request and enable it Dec 15 21:36:51 e.g. devm_clk_get() + clk_prepare_enable() Dec 15 21:37:05 and of course have a pinmux declaration for the clkout pin Dec 15 21:39:34 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. Dec 15 21:41:39 I don't know how fpgas are handled by linux, is there no support for declaring a clock? Dec 15 21:43:40 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 Dec 15 21:43:57 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 Dec 15 21:44:18 hahah Dec 15 21:47:32 various individual drivers in drivers/fpga do request clocks... specifically xilinx-pr-decoupler.c, altera-hps2fpga.c, socfpga-a10.c, and zynq-fpga.c Dec 15 21:49:37 someone tried to submit a userspace clock consumer device, but got rejected Dec 15 21:58:57 how come? Dec 15 21:59:24 something like passing through to pinout seems like it could be useful Dec 15 22:01:20 because of kernel devs thinking such things should be controlled by the kernel and not userspace Dec 15 22:04:54 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" **** BEGIN LOGGING AT Thu Dec 16 00:00:31 2021 **** ENDING LOGGING AT Thu Dec 16 02:59:56 2021