nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle
buckket has quit [Ping timeout: 250 seconds]
xet7 has quit [Quit: Leaving]
xet7 has joined #beagle
buckket has joined #beagle
vd has quit [Quit: Client closed]
vd has joined #beagle
dkaiser has joined #beagle
vagrantc has joined #beagle
mattb0ne has quit [Remote host closed the connection]
dkaiser has quit [Quit: Leaving]
vagrantc has quit [Quit: leaving]
buzzmarshall has quit [Quit: Konversation terminated!]
Guest56 has joined #beagle
Guest56 has left #beagle [#beagle]
Guest5 has joined #beagle
Guest563 has joined #beagle
Guest5 has quit [Ping timeout: 256 seconds]
Guest563 has quit [Client Quit]
Guest5 has joined #beagle
<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
<Guest5> could not find any technical solution to the situation. Thanks in advance for your help.
<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)
<zmatt> is the device also connected via usb in your case?
<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
vd has quit [Ping timeout: 256 seconds]
<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
<zmatt> though it's interesting that you're also seeing the issue without usb
<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
<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?
<Guest5> The hardware button of the device (not BBB's) sends the command sudo poweroff.
<Guest5> But the same thing happens when we use the switch on the BBB to turn it off
<zmatt> those trigger the same thing, they're both software requests
<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.
<Guest5> Even if I am mistaken, like I've said we've tried it without connecting anything except a 5V power supply (barrel jack)
<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
<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
<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)
<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
<zmatt> although that's not very elegant
<zmatt> this is purely a guess though, there's no way to begin debugging this without a scope trace
<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
<zmatt> but dunno, it's all I can think of
Guest5 has quit [Quit: Client closed]
rob_w has joined #beagle
otisolsen70 has joined #beagle
florian has joined #beagle
Mateen has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
Mateen has quit [Quit: Client closed]
Shadyman has quit [Quit: Leaving.]
rob_w has quit [Ping timeout: 252 seconds]
rob_w has joined #beagle
Posterdati has quit [Ping timeout: 250 seconds]
Posterdati has joined #beagle
ikarso has joined #beagle
otisolsen70 has quit [Quit: Leaving]
buzzmarshall has joined #beagle
otisolsen70 has joined #beagle
xet7 has quit [Quit: Leaving]
danny has joined #beagle
rob_w has quit [Remote host closed the connection]
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
vd has joined #beagle
robert_ is now known as Daulity
Guest7696 has joined #beagle
Guest7696 has quit [Client Quit]
Konsgn has joined #beagle
<Konsgn> Has anyone worked with fpga programming via spi port from the linux user space or kernel?
buckket has quit [Read error: Connection reset by peer]
lucascastro has quit [Ping timeout: 256 seconds]
buckket has joined #beagle
danny has quit [Quit: The Lounge -]
danny has joined #beagle
danny has quit [Quit: The Lounge -]
danny has joined #beagle
florian has quit [Quit: Ex-Chat]
danny has quit [Quit: The Lounge -]
danny has joined #beagle
jfsimon1981 has quit [Ping timeout: 260 seconds]
Posterdati has quit [Ping timeout: 252 seconds]
vagrantc has joined #beagle
Posterdati has joined #beagle
mru has quit [Ping timeout: 250 seconds]
mru has joined #beagle
<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)
<zmatt> the kernel has an pwm-omap-dmtimer driver for that
<zmatt> if you need it to be a clock device for the kernel, there's the clk-pwm driver for that
lucascastro has joined #beagle
<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 ...
<zmatt> ...standard regarding how fpgas are programmed
<Konsgn> true that, I was looking into the xilinx_spi_probe section of relevant drivers and this doc:
<Konsgn> was thinking of trying to use dmtimer7 to output a clock and pll-synthesize a master clock in the xilinx from that.
<zmatt> there's also clkout1 on P9.41
<zmatt> or clkout2, whatever it's called
<Konsgn> clkout2 is only for 32khz out though right?
<zmatt> nope
<Konsgn> interesting. I could use that then.
<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 ;)
<zmatt> (especially not via the beaglebone's headers anyway)
<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)
<Konsgn> yea, thinking 100mhz
<zmatt> the clock is &clkout2_ck
<zmatt> hmm, DT declares the divider with max-div=<8> but based on the TRM that should be max-div=<7>
<zmatt> (TRM says 0..6=/1../7 and 7=reserved)
<Konsgn> and modify the clocks entry?
<zmatt> no
<zmatt> generally speaking you should never modify a clocks property since it is a declaration of how the hardware is structured
<Konsgn> hmmm.
<zmatt> there's kernel APIs to change clocks or you can use assigned-clocks to do so in DT
<zmatt> something like this I think:
<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
<zmatt> *this is
<Konsgn> goes in root node?
<zmatt> normally goes in the device node for which these clocks should be setup
<zmatt> putting them in the root sounds like a bad idea
<Konsgn> so for a clockout pin it could just go into a &gpio node or something?
<zmatt> what does it have to do with gpio?
<zmatt> if your fpga has a node, that would be the logical place
<Konsgn> to get clockout on a gpio pin
<Konsgn> ahhh gotcha
<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
<Konsgn> okay, i see what you mean. too used to looking at all pins as gpio
<Konsgn> Thank you
<zmatt> your fpga node should also have clocks = <&clkout2_ck>; and the driver should request and enable it
<zmatt> e.g. devm_clk_get() + clk_prepare_enable()
<zmatt> and of course have a pinmux declaration for the clkout pin
thinkfat has joined #beagle
<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.
<zmatt> I don't know how fpgas are handled by linux, is there no support for declaring a clock?
<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:
<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
<Konsgn> hahah
<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
<zmatt> someone tried to submit a userspace clock consumer device, but got rejected
<Konsgn> how come?
<Konsgn> something like passing through to pinout seems like it could be useful
<zmatt> because of kernel devs thinking such things should be controlled by the kernel and not userspace
<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"
Konsgn has quit [Ping timeout: 256 seconds]
vd has quit [Quit: Client closed]
vd has joined #beagle
otisolsen70 has quit [Quit: Leaving]
vd has quit [Quit: Client closed]
vd has joined #beagle