ikarso has quit [Quit: Connection closed for inactivity]
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #beagle
Angel_Sosa has quit [Quit: Angel_Sosa]
starblue2 has joined #beagle
starblue1 has quit [Ping timeout: 240 seconds]
Shadyman has joined #beagle
Guest4026 has joined #beagle
vagrantc has quit [Quit: leaving]
buzzmarshall has quit [Quit: Konversation terminated!]
Guest4026 has quit [Quit: Client closed]
insurgent has joined #beagle
insurgent_ has quit [*.net *.split]
mru has quit [*.net *.split]
mru_ has joined #beagle
pbrobinson has quit [*.net *.split]
kveremitz has quit [*.net *.split]
pbrobinson_ has joined #beagle
v3r3mitz has joined #beagle
v3r3mitz is now known as kveremitz
Guest4026 has joined #beagle
ikarso has joined #beagle
rob_w has joined #beagle
Guest4026 has quit [Quit: Client closed]
Guest4026 has joined #beagle
LetoThe2nd has joined #beagle
florian has joined #beagle
x56 has quit [Quit: Ծ-Ծ]
x56 has joined #beagle
Guest4026 has quit [Quit: Client closed]
Guest11 has joined #beagle
Guest11 has quit [Client Quit]
linkliu60 has quit [Quit: leaving]
linkliu59 has joined #beagle
linkliu59 has quit [Client Quit]
linkliu59 has joined #beagle
Guest4026 has joined #beagle
linkliu59 has quit [Client Quit]
linkliu59 has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
mru_ is now known as mru
Shadyman has quit [Remote host closed the connection]
Guest4026 has quit [Quit: Client closed]
lucas__ has joined #beagle
lucas__ has quit [Ping timeout: 252 seconds]
Guest4026 has joined #beagle
lucas__ has joined #beagle
pbrobinson_ is now known as pbrobinson
Guest4026 has quit [Quit: Client closed]
Guest4026 has joined #beagle
GenTooMan has quit [Quit: Leaving]
GenTooMan has joined #beagle
buzzmarshall has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
rcn-ee_ has quit [Remote host closed the connection]
troth has joined #beagle
rob_w has quit [Quit: Leaving]
set_ has quit [Ping timeout: 268 seconds]
vd has joined #beagle
<vd>
hi there -- was there a fix for the PHY bug on the bbb causing the Ethernet link to be down sometimes?
Hunter has joined #beagle
<Hunter>
I'm looking for some good resources to learn the details of embedded linux and the BBB. I'm currently looking at J. Lions commentary on the unix source code, I was wondering if there was anything similar for embedded linux?
florian has quit [Quit: Ex-Chat]
Guest4026 has quit [Quit: Client closed]
mikkel has quit [Quit: leaving]
Hunter has quit [Quit: Client closed]
<zmatt>
vd: there are ways of reducing or eliminating it, though without a hardware patch the only reliable workaround seems to be to have software detect when the phy is in a broken state and trigger some external hardware that resets the bbb
<vd>
zmatt: thank you. Doesn't the bbb have a way to trigger a power cycle?
<zmatt>
no
<zmatt>
or, well, not really
<zmatt>
there's a way but it involves questionable poking in the pmic and probably violation of absolute maximum ratings
<vd>
the rtc line thing?
<zmatt>
yeah
<zmatt>
how dangerous it is will depend on the external hardware connected
<zmatt>
the major problem with it is that it leaves a few power supplies enabled, notably sys_5v and vdd_3v3b (which is the 3.3v supply available on the P9 header) while power-cycling others
<zmatt>
so any external hardware (or on-board hardware for that matter, like the eMMC or μSD card) that drives a processor I/O line high, powered by vdd_3v3b, while the processor itself is being power cycled will potentially fry that I/O
<vd>
problem is, the hard is in production for years now, cannot change it
<vd>
there's a custom cape on it though, what should I look for on the schematics, to see if there's any hardware solution by any chance?
<zmatt>
I mean, the only hardware solution would be a way to safely reset or power-cycle the beaglebone
<zmatt>
which is unlikely to be present unless implemented purposefully
<zmatt>
(there's also a software workaround for a subset of the phy problems (specifically when it's working fine but has the wrong phy address), but that workaround is already implemented in the beagleboard images and has been for a very long time afaik)
<vd>
that's what I want to confirm first with the design I'm working on
<zmatt>
jkridner: idea: since the eMMC reset line doesn't work for its intended purpose, maybe it could be repurposed for the Ethernet PHY reset to be able to truly fix the phy problem once and for all?
<vd>
zmatt the issue you're describing with the rtc line fix, is it a problem if triggered from within the bootloader instead of linux?
<zmatt>
vd: it doesn't matter where or how it's triggered, the problem is with the entire concept
xet7 has quit [Remote host closed the connection]
<vd>
ok, I was hoping maybe it was 'safer' if triggered from an early stage
<zmatt>
(and if that wasn't already clear from my description of the problem, then you're also in no position to analyze the situation for your hardware)
xet7 has joined #beagle
lucas__ has quit [Ping timeout: 240 seconds]
<vd>
trying my best
<zmatt>
well, it might be slightly safer in the sense that doing it in u-boot makes it easiest to ensure the eMMC and uSD buses are idle before performing the power-cycle
<zmatt>
*makes it easy
<zmatt>
but the main danger still comes from external hardware connected via the expansion headers
<vd>
I'm using barebox, it's funny because 'miitool' reports "link ok" regardless the PHY status, while 'dhcp' might not work ("Unable to find a PHY (unknown ID?)")
<zmatt>
if you're not using the bootloeader supplied with the beagleboard.org images then you might not have the software workaround I mentioned earlier
<zmatt>
so the phy issue will then affect you more severely than most users
<zmatt>
at least I think so, I'm not 100% sure whether that workaround is implemented in u-boot, the kernel, or both
<vd>
well, I'm won't be using u-boot, that's for sure ^^
<zmatt>
then you may need to reimplement the workaround, i.e. scan for the phy rather than assuming its id
<vd>
I can see the SYS_RESET# is wired somewhere, is it something you'd expect for a clean solution?
<zmatt>
??
<zmatt>
I don't know what you mean with that
<vd>
P9.10 I think
<zmatt>
what about it?
<vd>
nevermind, I'm not sure what I'm looking into from the schematics...
<zmatt>
my suggestion would be to port the partial software workaround to your custom setup
<zmatt>
that won't fix the problem but at least it will significantly reduce it
russ has quit [Ping timeout: 258 seconds]
<zmatt>
(or verify whether or not that fix is already in place for you, since like I said I'm not really sure where exactly it has been implemented)
<vd>
zmatt what does the unsafe rtc power cycling fix consist of? I'd like to try it as a PoC from the bootloader
rcn-ee has joined #beagle
GooberMan has joined #beagle
mranostaj has joined #beagle
russ has joined #beagle
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<vd>
zmatt also the eMMC reset line fix, could that be a simple wire to solder on the board?
mattb0ne has joined #beagle
<zmatt>
vd: second question: no, but there are simple hardware workarounds... my understanding was that the existence of those was not really relevant to you since your hardware is already deployed
<vd>
zmatt: true, but a technician soldering a wire during the week end might be an option, kinda
<zmatt>
vd: patch a schottky diode from the power button line (P9.09) to vdd_3v3b (P9.03/04)
<zmatt>
then if the system powers off it will automatically power back on
<zmatt>
which you can use to power-cycle the system
<vd>
zmatt only one of P9.03 or P9.04, right?
<zmatt>
they're the same thing
<vd>
got it
mattb0ne has quit [Remote host closed the connection]
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 240 seconds]
mattb0ne has joined #beagle
russ has quit [Ping timeout: 250 seconds]
mattb0ne has quit [Remote host closed the connection]
mattb0ne has joined #beagle
akaWolf has quit [Ping timeout: 252 seconds]
Guest469 has joined #beagle
Guest469 has quit [Client Quit]
Guest5 has joined #beagle
<Guest5>
Hello, I'm trying to figure out how to read analog voltages from the AIN0-6 pins on the beaglebone black rev C, running ubuntu 18.04
mattb0ne has quit [Ping timeout: 250 seconds]
<Guest5>
I've been able to read the GPIO pins by going to /sys/class/gpio
<Guest5>
going to the specific gpio pin
<Guest5>
then: cat value
<Guest5>
(after making sure direction is in)
<zmatt>
ubuntu isn't officially supported, but presumably analog inputs will work the same as on debian
<Guest5>
now I'm trying to figure out how to do the same for the analog in pins, but am having trouble finding the right directory
<Guest5>
but the articles I find seem to be out of date maybe, they're referncing paths that don't exist on my beaglebone
<Guest5>
or maybe they're for debian
<zmatt>
that's an article from 2014... that's not a good sign
<zmatt>
yeah no, that's definitely obsolete
<Guest5>
for sure
<Guest5>
do you know where I might be able to find more recent guidance?
<zmatt>
is iio_info installed?
GenTooMan has quit [Ping timeout: 240 seconds]
<zmatt>
(package libiio-utils)
<Guest5>
I don't think so
<Guest5>
should I install it?
<zmatt>
sounds like a good idea
<zmatt>
why are you using ubuntu instead of debian?
<Guest5>
because my project wants me to use ubuntu
<Guest5>
unfortunately that parts not really up to me
<Guest5>
unless I show definitively that it can't work on ubuntu
<zmatt>
does whoever decided that know that ubuntu is not officially supported and that using it means you're basically a guinea pig for a mostly-untested image?
<Guest5>
ok I'm installing it
<zmatt>
(on this hardware)
<zmatt>
"can't work on ubuntu" is an impossible criterium... this is linux, you can get anything to work if you spend enough time on it, that doesn't make it a good idea to do so necessarily
<Guest5>
I will pass this information along
GenTooMan has joined #beagle
<Guest5>
I installed libiio-utils
<zmatt>
iio_info show now list the adc device and the 8 analog inputs
<zmatt>
(this isn't the most convenient way to get that info, but it's the easiest way to confirm it's working)
<Guest5>
for sure
<Guest5>
ok, that seems to be working
<Guest5>
also, do you know if the analog inputs are configurable to read voltages up to 3.3 V?
<Guest5>
everything I read seems to indicate that they only go up to 1.8 but we were hoping to use them up to 3.3
<zmatt>
everything you've read is correct]
<zmatt>
if you put 3.3V on them you will destroy the beaglebone (or at least the analog input)
<Guest5>
ok, even with reconfiguration?
<zmatt>
there's nothing to configure
<Guest5>
(i.e. is it a hardware limitation)
<Guest5>
ok
<Guest5>
and is there a way to read analog pins without this utility?
<Guest5>
i.e. by like going to a specific location and using filesystem i/o
<Guest5>
like with the GPIO pins?
<zmatt>
to get just the raw value of a channel you can use: iio_attr -q -c TI-am335x-adc.0.auto voltage0 raw
<zmatt>
("voltage0" is the channel)
<zmatt>
where 0 = 0V and 4095 = 1.8V
<zmatt>
you can indeed also read it directly from sysfs
<zmatt>
let me see what the best way is to reliably find the path
<Guest5>
ok, thanks
<zmatt>
software can also use libiio or one of its bindings
<Guest5>
that iio_attr command gave me "iio_attr: command not found"
<Guest5>
although iio_info did work
<Guest5>
also, notably, I do not have a /sysfs directory
<zmatt>
/sys
<Guest5>
ok, yeah, /sys is where the gpios were
<Guest5>
/sys/class/gpio
<Guest5>
haven't been able to find any AIN pins in there though
<zmatt>
huh that's weird, what version of the package did apt install?
<Guest5>
I tried using the find command
<Guest5>
it says library version: 0.10
<zmatt>
oh that's really old
<Guest5>
weird
<Guest5>
I do have it hooked up to the internet
<Guest5>
and I think it's running the latest version of ubuntu 18.04
<zmatt>
maybe ubuntu is just behind, I don't know... like I've said a few times, ubuntu is not officially supported
<zmatt>
the official beagleboard.org debian buster IoT image ships with libiio-utils 0.19 installed
<Guest5>
gotcha
<Guest5>
ok, well maybe I can try to read it from the /sys path instead?
<Guest5>
and yeah, that's good to know
<Guest5>
I'm talking to my group about using a different board or a different OS
<zmatt>
the raw sysfs path for ain0 would be something like /sys/bus/iio/devices/iio:device0/in_voltage0_raw where the 0 in "voltage0" indicates the channel
<zmatt>
there's not really any good reason to use ubuntu instead of debian on a beaglebone
<zmatt>
ubuntu is debian-based, pretty much anything that runs on ubuntu will also work on debian
<zmatt>
anyway, the hazard with using the raw sysfs path is that it's absolutely not guaranteed that the ADC is iio:device0
<Guest5>
ah, ok
<Guest5>
so there's nothing along the lines of /sys/class/AIN/AIN0
<Guest5>
or something like that?
<zmatt>
the kernel will simply number iio devices sequentially in whatever order it encounters them... so maybe the ADC is right now the only iio device and therefore always device 0, but then if you later update the kernel or add some other device, it might become iio:device1 and your code would break if it blindly assumes it's iio:device0
<zmatt>
so the better solution is to scan for it based on name
<zmatt>
which is what libiio would normally do for you
<Guest5>
ah, gotcha
<Guest5>
yeah doing it raw based on the paths sounds bad based on that
<zmatt>
of course you can also scan for it manually
<zmatt>
or add an udev rule that creates a symlink for you
<Guest5>
I wonder why it's different for the AIN vs the GPIOs
<Guest5>
but ok, good to know
<zmatt>
it's not
<zmatt>
the assumption is also wrong for gpios
<Guest5>
so does controlling the GPIOs with that method also have this problem?
<zmatt>
yes, but with gpios you can often get away with it
<Guest5>
i.e. /sys/class/gpio/gpio35 may refer to different GPIOs at different times?
<zmatt>
because even if you add a gpio extender later on, most likely the platform devices still get probed first and in the expected order... hopefully... maybe...
<Guest5>
ah, I see
<zmatt>
but the kernel definitely doesn't guarantee this at all
<zmatt>
it just happens to be work in practice, so far
<Guest5>
and if we don't plan to modify the beaglebone hardware, only the stuff that plugs into it
<Guest5>
is that ok?
<Guest5>
the rule I found online was that GPIOX_Y=gpio(32*X+Y)
<zmatt>
yeah that rule works in practice, typically
<zmatt>
but there's no guarantee
<Guest5>
but that rule is not always true is what you're saying?
<zmatt>
my preferred solution is to use an udev rule to create named symlinks
<Guest5>
assuming there are different headers plugged into the BBB, I guess>
<Guest5>
*?
<zmatt>
it depends on what devices existed in the kernel's worldview... that doesn't really depend on what's physically attached (except to discoverable buses like usb) but based on what the kernel has been told via Device Tree
<zmatt>
*exist in
<Guest5>
ok, interesting
<zmatt>
do you gpio devices exist automatically at boot, or are you manually exporting them?
<zmatt>
*your
<zmatt>
(I don't know anything about the ubuntu image)
<Guest5>
I'm not manually creating them
<Guest5>
so I think they exist at boot
<zmatt>
then if you create a file /etc/udev/rules.d/gpio-symlinks.rules with this content: https://pastebin.com/qZZmQQQg
<zmatt>
then update your initramfs (if you have one) with: sudo update-initramfs -u
<zmatt>
and reboot
<zmatt>
then you should have a directory /dev/gpio/ containing symlinks for all gpios
<Guest5>
ok, good to know
<zmatt>
a similar symlink could be made for the adc
<Guest5>
those are the AIN pins right?
<zmatt>
"ain" = adc input
<Guest5>
gotcha
<Guest5>
so another question I had is, are the pins with specific functions potentially reconfigurable?
<Guest5>
like, for example, P8.26-30
<Guest5>
seem to be reserved for usage for "lcd pclk and lcd oe", respectively
<Guest5>
is that adjustable without booting from the SD card?
<zmatt>
see the P8 and P9 tabs of my pins spreadsheet for possible pin modes: https://goo.gl/Jkcg0w#gid=1847985463
<zmatt>
P8.27-46 are used for video output if hdmi video is enabled
<Guest5>
ok, so just look at the columns to the right of the relevant ones on P8?
<Guest5>
a little confused by how to read this document
<zmatt>
hdmi video can be disabled by uncommenting the "disable_uboot_overlay_video=1" setting in /boot/uEnv.txt ... at least on debian, perhaps also on ubuntu
<Guest5>
I see for B27 and B28, it lists "edio in, pru 1 out 10", etc.
<zmatt>
this shows for each pin the various functionalities that the hardware supports
<zmatt>
along with assorted notes
<Guest5>
oh ok, so if we turn that off can B26-30 be usable as regular GPIOs?
<Guest5>
gotcha
<Guest5>
and then can everything be used as regular GPIOs if the special function is disabled in /boot/uEnv.txt?
<zmatt>
P8.27-30 can then be used as normal gpios (P8.26 can be used as normal gpio regardless of whether hdmi is enabled)
<zmatt>
P8.31-46 also, as long as the big yellow warning is heeded
<Guest5>
gotcha
<Guest5>
yeah we are heeding the yellow warning
<Guest5>
so it seems like all of the GPIO pins can be used as regular GPIO pins, assuming that we turn off a few things in /boot/uEnv.txt?
<Guest5>
with the exception of the eMMC ones? (and then even we can use them if we boot from the SD card and turn off eMMC)
<zmatt>
eMMC pins are best left alone... even if you boot from SD card, the eMMC is still connected to those pins and gets probed during boot
<Guest5>
gotcha
<Guest5>
but are we good on the others if we jjust turn all the stuff like HDMI off?
<zmatt>
yep
<zmatt>
well, and P9.19-20 are configured as i2c by default and will be probed during boot
<zmatt>
but can be reconfigured
<zmatt>
also, I seem to have a working udev rule for the adc
<Guest5>
and the reconfiguration process, is it just turning some stuff off in /boot/uEnv.txt?
<Guest5>
or is that whole thing with compiling the dtsi file?
GenTooMan has quit [Ping timeout: 250 seconds]
<zmatt>
no, runtime configuration using config-pin, same as all other pins
<Guest5>
ok, so either config-pin, to config at runtime
<Guest5>
or the dtsi overlay for doing at boot?
<zmatt>
yes
<Guest5>
gotcha
<zmatt>
with that udev rule, the raw ain0 readout would be /dev/adc/in_voltage0_raw
<Guest5>
ok, good to know
<Guest5>
alright, I think you answered all my questions!
<zmatt>
this would be the ain0 voltage in μV: echo $(( $(cat /dev/adc/in_voltage0_raw) * 40000 / 91 ))
<Guest5>
ah, great
<Guest5>
that is good to know too
<zmatt>
I guess mV would be more appropriate...
<zmatt>
for ch in {0..7}; do echo "ch $ch = $(( $(cat /dev/adc/in_voltage${ch}_raw) * 40 / 91 )) mV"; done
<zmatt>
(ch7 is vdd_3v3b/2 hence should be around 1.65-1.7 V)
<Guest5>
ok, noted
<Guest5>
thanks again
GenTooMan has joined #beagle
Shadyman has joined #beagle
alan_o has quit [Ping timeout: 240 seconds]
alan_o has joined #beagle
zjason` has joined #beagle
zjason has quit [Ping timeout: 250 seconds]
alan_o has quit [Ping timeout: 250 seconds]
alan_o has joined #beagle
vd has quit [Quit: Client closed]
shoragan has quit [Ping timeout: 255 seconds]
shoragan has joined #beagle
russ has joined #beagle
Guest5 has quit [Quit: Client closed]
Guest56 has joined #beagle
<Guest56>
Hello, I am running a beaglebone black rev C, and am trying to use the config-pin utility to reconfigure some of the special-purpose GPIO pins at runtime
<Guest56>
it works for some pins, i.e.:
<Guest56>
config-pin p8.26 gpio
<Guest56>
but does not work for the ones that are not regular GPIO by default (the ones I'm concerned with).
<Guest56>
for example, config-pin p8.26 gpio returns:
<Guest56>
p8_27 pinmux file not found!
<Guest56>
bash: /sys/devices/platform/ocp/ocp*P8_27_pinmux/state: no such file or directory
<zmatt>
unrelated to your question: I recommend avoiding the "gpio" mode since it means "gpio with pull-up/down disabled" ... use "default" instead or explicitly use "gpio-pu" or "gpio-pd"
<zmatt>
P8.27-46 are used by hdmi video if enabled
<Guest56>
ok, gotcha
<Guest56>
ah
<Guest56>
and do I turn it off using config-pin?
<Guest56>
or using the /boot/uEnv.txt file or something like that?
<zmatt>
to free those up for other uses, uncomment "disable_uboot_overlay_video=1" in /boot/uEnv.txt
<Guest56>
ah
<zmatt>
but heed the caution in bright yellow on the P8 tab of my pins spreadsheet: https://goo.gl/Jkcg0w#gid=1847985463
<Guest56>
and then I'm guessing it's similar if I want to use the other groups, like I should disable overlay_audio and overlay_wireless as well?
<Guest56>
will do
<zmatt>
overlay_wireless is not applicable on the BBB since it has no wireless
<Guest56>
ok, so that should already be good?
<zmatt>
it is only relevant on the beaglebone green wireless
<zmatt>
audio is only relevant is video is enabled, since you can disable hdmi audio while keeping video enabled, but disabling video will disable hdmi entirely including audio
<Guest56>
ok, so it sounds like that should free them all up to be reconfigured then
ft has quit [Ping timeout: 268 seconds]
<Guest56>
also, is there a way to reconfigure all the GPIO pins possible to be "default" mode at once?
<zmatt>
yep, except the eMMC pins which should just be left alone
<Guest56>
or do I need to do them one by one with config-pin?
<zmatt>
they're all "default" by default, except P9.19-20
<Guest56>
huh, ok
<Guest56>
that's assuming hdmi video is disabled I'm guessing?
<zmatt>
yes
<Guest56>
ok cool
<Guest56>
so it sounds like all I should need to do is disable that and reboot
<zmatt>
actually all configurable pins are "default" by default, that's why it's called "default"... but for P9.19-20 that default is i2c, for all other configurable pins it's gpio