CrazyEddy has joined #beagle
Shadyman has joined #beagle
zjason` is now known as zjason
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 250 seconds]
akaWolf has quit [Ping timeout: 272 seconds]
vagrantc has quit [Quit: leaving]
akaWolf has joined #beagle
mag has quit [Remote host closed the connection]
mag has joined #beagle
lucascastro has quit [Ping timeout: 272 seconds]
Guest49 has joined #beagle
<Guest49> I would like to add additional SRAM and RTC to the beaglebone green board
buzzmarshall has quit [Quit: Konversation terminated!]
johanhenselmans_ has joined #beagle
johanhenselmans has quit [Ping timeout: 256 seconds]
johanhenselmans_ is now known as johanhenselmans
<zmatt> Guest49: sram? o.O
<zmatt> oh, as in, battery-backup ram?
<zmatt> an RTC is pretty straightforward, you just connect one via i2c (and inform linux about its existence using a DT overlay)
Guest24 has joined #beagle
<Guest24> Hello, I am a new customer, interested for one of our product for an automotive customer. I need a customer service email please, where I could send my inquiry. Thank you!
Guest24 has quit [Client Quit]
florian has joined #beagle
Guest49 has quit [Quit: Client closed]
Shadyman has quit [Quit: Leaving.]
lucascastro has joined #beagle
buckket has quit [Read error: Connection reset by peer]
buckket has joined #beagle
nmingotti has joined #beagle
<nmingotti> I guys, i wanted to let you know something i just discovered adn brought me on the border of madness
<nmingotti> so, as you know since a long time i cool the BB-AI via Fan-Cape, and i control Fan-Cape via a BB PWM
<nmingotti> ok, this thing had a problem, sometimes it didn't work
<nmingotti> expecially now, that i changed the OS the probability of non-working was super high
<nmingotti> so, i  was forced to find the reason
<nmingotti> the reason is, even if systemd sees the PWM and run the appropriate controller
<nmingotti> it IS NOT GUARANTEED that the pwm is readt to be accessed !
<nmingotti> I solved in this way, the script that goes to set the speed does a waste loop before starting, in which is just checks if it is able to read the appropriate pwm directory. If it doesn't it just wait and retry
<nmingotti> Of course, this is not super but it is the best i could figure
<nmingotti> it would be better if systemd told me that a device is ready when it is really ready
<nmingotti> in the end i think that it is udev that is signaling to be ready when it is actually not ready
<nmingotti> anyway, this problem is solved i can move forward and try to close this project once and for all
<set_> Hello...way to go!
<set_> It is super early and I am full of learning experiences today. Good on you!
<set_> First breakfast!
<nmingotti> good day set_ !
<set_> good day!
<nmingotti> i post you what i see in my journalctl for the service controling the fan speed
<nmingotti> this just to show it can take several seconds for the pwm dir to become available
<set_> Oh. No. I cannot handle it right now. But soon. I will check back later.
<nmingotti> i retry every 1 sec
<set_> Okay.
<nmingotti> i need to go back to work, this machine needs me ;)
<nmingotti> have a nice day
<set_> You too!
set_ has quit [Remote host closed the connection]
akaWolf has quit [Ping timeout: 252 seconds]
akaWolf has joined #beagle
akaWolf has quit [Ping timeout: 252 seconds]
<zmatt> nmingotti: if you have a service that depends on the presence of devices, there are ways to declare that to systemd
<zmatt> nmingotti: ohey I just noticed you already ran into that before and got the necessary workaround in the udev rule... sort of, it's a bit weird: https://pastebin.com/07ThYrQa lines 43-46 is a custom rule you have to detect when ehrpwm1a shows up, create a symlink /dev/fan-cape-pwm for it, change its group to gpio (pointlessly since that's already done for all pwm devices by line 8), and tag it for ...
<zmatt> ...systemd to allow systemd services to declare dependency on it
<zmatt> I'm actually not sure what the name of the device unit is in that case though, because of the dashes
<zmatt> if you called it /dev/pwm/fan then the device unit name would be dev-pwm-fan.device
<zmatt> /dev/fan-cape-pwm becomes dev-fan\x2dcape\x2dpwm.device which looks kinda gross
nmingotti has quit [Quit: Client closed]
akaWolf has joined #beagle
florian has quit [Quit: Ex-Chat]
Guest2946 has joined #beagle
<Guest2946> Hello, I'd like to know what is the min-max ambient temperature range for Beaglebone AI. I can't find this data in the documentation.
<zmatt> hmm, that sounds like it would be hard to specify? since that would depend on usage (e.g. cpu load, use of auxiliary cores) and whether any active cooling is used (e.g. a fan)
<zmatt> and the min ambient temperature may be lower than the min temperature for the components if the board is kept powered and able to keep itself warm
<zmatt> for heavier loads and/or warmer environments, a cooling solution may be advisable to avoid cpu throttling
<zmatt> that's my understanding anyway
<Guest2946> Thanks! We were using the industrial version of the Beaglebone that works between -40 +85 because the system have to start working at min 0°C. Since we are searching something more powerful I'd need to know if also the BB AI can start at 0°C
<zmatt> the SoC itself should be fine with that afaict, but of course that's not the only component on the board and I'm kinda too lazy to check them all :)
<zmatt> the RAM specifies 0͏ ͏°C - 95 ͏°C
otisolsen70 has joined #beagle
<zmatt> the USB Type-C controller is 0 to 70 ͏°C
<Guest2946> I think that the problem is the RAM  that at start-up with 0°C has no margin and RAM should be immediately working, the same for eMMC other parts could wait for the Soc that make the PCB warmer after few seconds
<Guest2946> Thanks a lot!
Guest2946 has quit [Quit: Client closed]
<zmatt> other parts I've checked have lower min temperature
<zmatt> the RAM and type-C controller were the only two I encountered with min 0 ͏°C, but I've only checked a few components
nmingotti has joined #beagle
<nmingotti> damn i was not logged in, i hope my message arrived anyway ;)
lucascastro has quit [Read error: Connection reset by peer]
lucascastro has joined #beagle
<nmingotti>  i also saw it is the second time you tell me to uncomment the two lines in rule 81. I had it in my notes. But that BeagleBoard note files start to be super large (> 100 pages) so i have difficulty also remembering what the hell i wrote there ;)
<zmatt> nmingotti: what message? did you see my reply earlier?
<nmingotti> i saw it moments ago
<nmingotti> then i wroute about ten lines with links etc.
<zmatt> none of that arrived
<nmingotti> damn it
<nmingotti> let me see if i can copy paste from my screen
<zmatt> btw, you should probably consider putting the custom udev rule for your fan in a separate file instead of appending it to a package-provided udev rule file
<nmingotti> i considered that, but then, i choose another path
<zmatt> to ensure the custom rule won't accidently get overwritten by an udpate
<nmingotti> ah ! that is a very good argument
<zmatt> whether udev rules are in the same or separate files makes no functional difference, it's just about maintainability
<nmingotti> wait, let me show you one thing
<nmingotti> the last part of my udev rule now looks like this : https://pastebin.com/KZaAasJM
<nmingotti> forget the group 'gpio' i red that
<zmatt> udev takes all rules files in /etc/udev/rules.d/ and /lib/udev/rules.d/ (with files in the former location overriding files in the latter location if they have the exact same name), sorts the list of files by name (asciibetically), and concatenates them
<nmingotti> oh, i see
<zmatt> wtf what did you do?
<zmatt> what am I even looking at?
<zmatt> your previous rule looked fine
<nmingotti> but this works ;P
<zmatt> apart from the superfluous (but not harmful) chgrp
<zmatt> this is a complete mess and breaks the way these rules were intended to work
<nmingotti> i restricted the devices to link to only one
<zmatt> by number, which is picked arbitrarily by the kernel
<zmatt> none of this makes sense
<zmatt> why did you do this?
<nmingotti> because i saw an error in `journalct -xe` about PWM, always
<zmatt> what error?
<nmingotti> wait, i thik i copied it iin my "last notes" file
<nmingotti> yes, i have it, here: https://pasteboard.co/FCiDw0d9ZyLD.png
<nmingotti> there was no way to kick it out, also deleting all my stuff from the rule
<nmingotti> so, i though, there could have been some attempt to overwrite the simlinks
<zmatt> this is strange
<nmingotti> then i tried to have the system write only one symlink, and the problem was gone
<zmatt> that doesn't explain what's happening
<nmingotti> i must go now, i will probably be back this evening
<nmingotti> bye
<jfsimon1981> hi goot evening
nmingotti has quit [Ping timeout: 256 seconds]
<zmatt> heh, found nmingotti's udev rule bug
<zmatt> = vs ==
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle
m-atoms has joined #beagle
otisolsen70 has quit [Quit: Leaving]
nmingotti has joined #beagle
nmingotti has quit [Ping timeout: 256 seconds]
dmh has quit [Quit: ZNC - https://znc.in]
thinkfat_ has quit [*.net *.split]
agraf has quit [*.net *.split]
shoragan has quit [*.net *.split]
ayjay_t has quit [*.net *.split]
zmatt has quit [*.net *.split]
agraf has joined #beagle
shoragan has joined #beagle
thinkfat_ has joined #beagle
zmatt has joined #beagle
ayjay_t has joined #beagle