<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 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
<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