buzzmarshall has quit [Quit: Konversation terminated!]
Guest4026 has joined #beagle
Guest4026 has quit [Quit: Client closed]
ikarso has joined #beagle
LetoThe2nd has joined #beagle
rob_w has joined #beagle
akaWolf has joined #beagle
rob_w has quit [Remote host closed the connection]
rob_w has joined #beagle
akaWolf has quit [Remote host closed the connection]
GenTooMan has quit [Ping timeout: 250 seconds]
florian has joined #beagle
GenTooMan has joined #beagle
akaWolf has joined #beagle
GenTooMan has quit [Ping timeout: 250 seconds]
akaWolf has quit [Ping timeout: 250 seconds]
akaWolf has joined #beagle
GenTooMan has joined #beagle
alan_o has quit [Ping timeout: 250 seconds]
alan_o has joined #beagle
Stanto has quit [Read error: Connection reset by peer]
johanhenselmans_ has joined #beagle
johanhenselmans has quit [Ping timeout: 250 seconds]
johanhenselmans_ is now known as johanhenselmans
Guest4026 has joined #beagle
Shadyman has quit [Remote host closed the connection]
GooberMan has left #beagle [#beagle]
Guest4026 has quit [Quit: Client closed]
Guest4026 has joined #beagle
Guest4026 has quit [Quit: Client closed]
Guest4026 has joined #beagle
Daulity has joined #beagle
<Daulity>
hey
<Daulity>
i see edma interrupts in /proc/interrupts
<Daulity>
about 30 a seconds this is probably the framebuffer ?
<zmatt>
no, video doesn't use edma
<Daulity>
question is which options do disable any kind of video like framebuffer and or video card stuff
<Daulity>
because my platform doesn't use any of that
<zmatt>
uncomment disable_uboot_overlay_video=1 in /boot/uEnv.txt
<zmatt>
(although actual video output won't begin until a hdmi monitor is detected anyway)
<zmatt>
most likely the edma activity will be from hdmi audio, not video... though disabling video will disable hdmi entirely including audio
Guest4026 has quit [Quit: Client closed]
<Daulity>
I am not sure that is why i asked :)
<zmatt>
well I can only guess at what's using edma on your system of course, but I do know it's not the display controller since it uses its own integrated dma controller for outputting framebuffers rather than using edma
<zmatt>
and I do know that audio, when enabled, uses edma
<zmatt>
if you have a strong desire to identify edma activity, I have a utility for inspecting the edma controller (via /dev/mem)
kveremitz has quit [*.net *.split]
Patater has quit [*.net *.split]
Daulity has quit [*.net *.split]
outrageous_ has quit [*.net *.split]
moto-timo has quit [*.net *.split]
_av500_ has quit [*.net *.split]
noahm has quit [*.net *.split]
Daulity has joined #beagle
kveremitz has joined #beagle
Patater has joined #beagle
outrageous_ has joined #beagle
_av500_ has joined #beagle
noahm has joined #beagle
moto-timo has joined #beagle
M-blaise has quit [Ping timeout: 250 seconds]
M-blaise has joined #beagle
Guest4026 has joined #beagle
GenTooMan has quit [Ping timeout: 250 seconds]
rob_w has quit [Quit: Leaving]
GenTooMan has joined #beagle
<rcn-ee>
@mranostaj, sorry i missed your u-boot pull request, just noticed it today when i pushed something similar, i guess i didn't configure that repo for notices, weird.. anyhow, the bb-u-boot-am335x-evm deb package is building now..
<rcn-ee>
i'm also testing v2021.10-rc2 right now, i'll be dropping that into bullseye first to not break older installs..
charlie5 has quit [Ping timeout: 250 seconds]
charlie5 has joined #beagle
buzzmarshall has joined #beagle
<rcn-ee>
@mranostaj, bb-u-boot-am335x-evm is now pushed out to the repo..
<kveremitz>
uboot bump incoming?! :P
<rcn-ee>
@kveremitz, you can play with it today, bb-u-boot-am335x-evm is the default 2019.04, bb-u-boot-am335x-evm-beta is 2021.10-rc2
<kveremitz>
I got a sulky UPS to fix, otherwise I'd give it a roll .. and a sad beagle also :(
<kveremitz>
but I'm somewhat perplexed about said UPS, since I tested it and its battery not long ago ..
<rcn-ee>
i don't understand ups batteries, mine started buzzing about a month ago, replaced last year...f crap, time to order another replacment.. might be time to just rig a car battery instead..
<kveremitz>
mebbie!
vd has joined #beagle
<ketas>
or go lithium
<ketas>
i know, i know, huge step and you can miss and fall downstairs
<ketas>
lead acid already sucks and those upses just boil them dry
Guest4026 has quit [Quit: Client closed]
<kveremitz>
rotating disc... :p
<rcn-ee>
i'm tempted to just swap to a normal car battery, it's sealed lead acid that's alaways a problem.. i'll have to vent it outdoors..
<tbr>
I replaced the SLA pack in an UPS with a 24V group of prismatic LiFePo4 cells and a beefy BMS. Cost a pretty penny, but hey, it's also fun and should last "forever"
florian has quit [Quit: Ex-Chat]
Guest4026 has joined #beagle
<kveremitz>
bleh unplugged all the outlets, still won't fire. Guess I'd better open an order for some batteries. At least they're the super-common 7Ah size..
Guest40269 has joined #beagle
Guest4026 has quit [Ping timeout: 246 seconds]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
vd has quit [Quit: Client closed]
Guest40269 has quit [Quit: Client closed]
Shadyman has joined #beagle
GenTooMan has quit [Ping timeout: 250 seconds]
charlie5 has quit [Read error: Connection reset by peer]
GenTooMan has joined #beagle
vd has joined #beagle
<vd>
zmatt: hi! is `rtcwake -m off -s 5` supposed to trigger a powercycle via RTC on the BeagleBone Black?
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt>
vd: if you want to know why he made his tools the way he did you'd need to ask him, not me
<zmatt>
I don't know anything about his software other than that it exists
GenTooMan has quit [Ping timeout: 240 seconds]
<zmatt>
also keep in mind he uses the ancient kernel 3.8 and I don't know what did and didn't work back then
<vd>
zmatt: I just assumed you knew the bbb really well (as well as its RTC and its kernel support) so I allowed myself to poke you, sorry for the noice ;)
<zmatt>
I do, but I have never looked at what his tool does or why it does it the way it does
<zmatt>
I've also never used rtcwake since it's not really supported on the BBB (since entering rtc-only mode is defeatured in the am335x, and entering it causes a hazardous situation on the bbb as I explained)
<zmatt>
but I do know it works, I have experimented with rtc-only mode on a patched BBB, but my experiments were done in u-boot rather than in linux
drewfustini has quit []
drewfustini has joined #beagle
bradfa has quit []
bradfa has joined #beagle
vagrantc has joined #beagle
mgsb has quit []
mgsb has joined #beagle
M-blaise has quit [Ping timeout: 240 seconds]
lucascastro has joined #beagle
vigneshr has quit []
vigneshr has joined #beagle
russ has quit [Ping timeout: 250 seconds]
vagrantc has quit [Quit: leaving]
lucas_ has joined #beagle
lucascastro has quit [Read error: No route to host]
lucas_ has quit [Ping timeout: 240 seconds]
lucas_ has joined #beagle
charlie5 has joined #beagle
Guest46 has joined #beagle
<Guest46>
hello, I have a beaglebone black rev C and am looking into reading from the GPIO and analog pins
<Guest46>
for the GPIO pins it looks like I can read their values in /sys/class/gpio/specific_gpio/value
<Guest46>
I was wondering if there's a more computationally efficient way to do this? (some way that avoids opening and closing a filestream every time I want to query a pin)
<zmatt>
well you don't need to open/close it, you can just use a single pread() call
<Guest46>
like maybe a utility that does it in a different way
<zmatt>
(don't need to open/close it for every read)
<Guest46>
ah that's good
<zmatt>
"a utility" sounds like you're doing bash scripting, in which case asking about efficiency is a bit silly since bash scripting isn't efficient to begin with
<Guest46>
I'm not trying to do it in bash scripting, rather, in C++
<Guest46>
so if I'm understanding correctly, pread/pwrite do file i/o without opening and closing the file somehow?
<Guest46>
so less computational overhead?
<zmatt>
no
<zmatt>
you still need to open it once
<zmatt>
but there's no need to close and reopen it every time you want to read
<zmatt>
just keep it open
<zmatt>
using pread() instead of read() avoids having to lseek() back to the start each time
<Guest46>
huh ok
<Guest46>
then are other threads able to write to them while you're doing that?
<Guest46>
or once you have it open is it locked?
<zmatt>
keeping a file open does not lock it, though it seems odd to me you'd have a good reason to access one gpio by multiple processes/threads
<zmatt>
threads are generally best avoided anyway, especially on a single-core cpu like the one on the beaglebone... you just add complexity and make things slower
<Guest46>
ok, yeah I'm not sure how it'll be organized yet
<Guest46>
but noted
russ has joined #beagle
<Guest46>
and then to follow up on our conversation yesterday about analog pins:
<Guest46>
yesterday you were telling me that it's not reccomended to read analog pins based on their location in the filesystem, cause that's mutable
<Guest46>
and that either making a udev rule or using a utility that scans for them is the way to go
<zmatt>
if you need even higher gpio performance there's always the option of doing direct access via /dev/mem though you obviously need to really know what you're doing in that case. the highest gpio performance is available by running code on the PRU cores and using their dedicated fast GPIOs, which the PRU core can read in a single 5ns instruction (which is actually faster than the time it takes for the ...
<zmatt>
...voltage at the chip boundary to be propagated to the PRU core)
<Guest46>
I looked at the udev rules you pasted, but I was wondering what utility you would reccomend as an alternative?
<zmatt>
why not use the udev rule? that's by far the easiest solution
<Guest46>
gotcha
<Guest46>
yeah I don't think we want to go that deep, unless we're forced to by speed limitations
<zmatt>
like, just save it in /etc/udev/rules.d/, do "sudo update-initramfs -u" and reboot
<Guest46>
I guess I don't mind using it, but the issue is more that I don't understand how it works
<zmatt>
also, while I suspected you were the same guy from earlier but it's rather difficult to tell when you're named "Guest46" .. it would be helpful to choose a better name for yourself (you can configure it when logging on or change it using the /nick command)
<Guest46>
yeah good call
<Guest46>
I will choose a consistent name from now on
<Guest46>
oops that was the wrong udev rule
<Guest46>
here's the one for analog pins:
<zmatt>
yeah, so udev detects devices when they show up and is responsible for things like setting permissions and creating symlinks
<zmatt>
based on rules in /lib/udev/rules.d/ for distro-provided rules and /etc/udev/rules.d/ for custom rules
<zmatt>
(a file in /etc/udev/rules.d/ will override one in /lib/udev/rules.d/ if it has the exact same name)
<Guest46>
so as far as I can tell, this replaces /sys/bus/iio/devices/%k with /dev/adc%k"
<zmatt>
it creates a symlink
<Guest46>
so why not just use /sys/bus/iio/devices/%k in the first place and skip the rule?
<ketas>
tbr: how do you manage charge control, with own circuit part of that bms?
<zmatt>
Guest46: it creates a symlink from a fixed location /dev/adc (not "/dev/adc%k") to /sys/bus/iio/devices/%k where %k is replaced by the actual name of the device (e.g. "iio:device0")
<zmatt>
Guest46: which means you can then access it at /dev/adc without having to know that actual device name
<zmatt>
if in the future it happens to be /sys/bus/iio/devices/iio:device1 then that's what /dev/adc will point to
<zmatt>
your application won't have to know or care
<zmatt>
the udev rule recognizes the device based on the driver being used (TI-am335x-adc)
<zmatt>
which you could theoretically do manually by scanning through all iio devices and checking which driver they use, but it's kinda silly to do that when udev exists to perform that task for you
<Guest46>
ok, so when I access it after created this rule, it'll be at /dev/adc/AIN0-6?
<Guest46>
or something like that?
<zmatt>
/dev/adc/in_voltage0_raw
<Guest46>
ah, I see, so it's scanning based on the drivers
<Guest46>
that was part of what I was missing
<Guest46>
I thought it was just renaming everything in the one directory to the other
<Guest46>
ok, so in_voltage(0-6)_raw?
<zmatt>
yes
<zmatt>
OH, also, that udev rule is missing a \
<Guest46>
ok, and the udev rule is telling which ones are which because all the analog input pins use the same drivers?
<Guest46>
missing a \ or /?
<zmatt>
\, fixed it
<zmatt>
Guest46: there's only one adc device, udev is not concerned with the individual inputs which are simply properties on the adc device
<Guest46>
ah I see, thanks
<zmatt>
so that udev rule is saying: when a device is added (ACTION=="add") in the iio subsystem (SUBSYSTEM=="iio") whose kernel-assigned name starts with "iio:device" (KERNEL=="iio:device*") which is a component of a device that uses the "TI-am335x-adc" driver (DRIVERS=="TI-am335x-adc") then run the command "/bin/ln -sT '/sys/bus/iio/devices/%k' /dev/adc" where %k is replaced by the kernel-assigned name of ...
<zmatt>
...the device
<zmatt>
the \ is needed to split one rule across multiple lines, which I did for clarity
<Guest46>
ensure all necessary drivers are built into the linux image!
<zmatt>
uhh
<Guest46>
depmod: ERROR: could not open directory /lib/modules/4.19.8-arm7-x11: no such file or directory
<zmatt>
that kernel release version looks utterly weird to me
<zmatt>
what does "uname -r" say?
<Guest46>
ah, maybe this is cause I'm running ubuntu
<Guest46>
18.04
<Guest46>
uname -r produces:
<Guest46>
4.14.79-ti-r84
<zmatt>
so wtf is update-initramfs smoking about a "4.19.8-arm7-x11" kernel
<zmatt>
maybe add -k $(uname -r) as option to update-initramfs
<Guest46>
haha
<Guest46>
ok
<Guest46>
ok that worked
<Guest46>
still got some warnings but no errors
<zmatt>
I mean, you probably don't need initramfs at all, it just slows down boot... but at long as you have one it needs to be kept uptodate :P
<Guest46>
interesting, what is it for?
<zmatt>
initramfs is basically a small filesystem image that is passed to the kernel by the bootloader, and the kernel will initially boot into that and leave it to deal with locating and mounting the root filesystem (and then switch to that and execute its /sbin/init)
<Guest46>
huh ok
<zmatt>
its primary use is when the kernel cannot mount the root filesystem by itself, for example because one or more necessary drivers are built as modules instead of being compiled into the kernel, or if the root filesystem has some complications that need to be dealt with such as RAID or encryption
<Guest46>
I rebooted and I'm able to cat out the raw values for /dev/adc/in_voltage(0-6)_raw
<Guest46>
so I think it worked?
<zmatt>
yep
<Guest46>
awesome, thanks!
<Guest46>
so then, for the GPIO ones, you have this rule: