ikarso has quit [Quit: Connection closed for inactivity]
<set_>
What are you guys doing?
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #beagle
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 272 seconds]
mattb0ne has quit [Ping timeout: 265 seconds]
<zmatt>
this is fascinating... co-worker left a BBB on my desk with a note saying it was "fried" (haven't seen him yet to ask for details)... I tested it; it powers on, it draws a normal amount of current and all supplies show normal voltages
<zmatt>
so I tried booting it from sd card, and the first time it actually seemed to boot a decent way into linux (based on led activity) but then got stuck in some way suggesting maybe eMMC controller issues... but it also didn't respond via ethernet nor on the serial console
<zmatt>
so I tried power cycling while monitoring the serial console... it seems I was just lucky the first time, since I've not been able to reproduce it: it usually doesn't get further than U-Boot SPL, the few times it does it crashes somewhere in u-boot or in very early kernel
<zmatt>
wtf did he do to this beaglebone
<zmatt>
attempting to boot from eMMC is even less successful... I've seen the U-Boot SPL prompt exactly once so far
<zmatt>
it also seems to be progressively deteriorating
mattb0ne has joined #beagle
<GenTooMan>
zmatt, might be good to ask for details to see if the problem can be repeated otherwise it's What The Heck problem and potentially a waste of your time to figure out.
<zmatt>
I'm just puzzled how one manages to get it to be *this* broken without an internal short on one of the supplies
<zmatt>
like, I've previously seen a board that couldn't boot from eMMC or SD, but there the 3V3B measured to be way lower than 3.3V and it started to emanate a crispy smell
<GenTooMan>
hmm any way to force a boot from SPI/QSPI/
<zmatt>
the only thing that eMMC boot and μSD boot have in common is the 3.3V supply, the cortex-a8 trying to boot, and the SoC interconnect that connects the cortex-a8 to the two mmc/sd controllers
<zmatt>
and I measured the 3.3V supply
buzzmarshall has quit [Quit: Konversation terminated!]
<zmatt>
(if the ddr3 ram were the problem then it would at least get to U-Boot SPL consistently, but it doesn't even do that)
mattb0ne has quit [Ping timeout: 272 seconds]
samael has joined #beagle
rob_w has joined #beagle
LetoThe2nd has joined #beagle
ikarso has joined #beagle
Shadyman has quit [Quit: Leaving.]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
jkridner[m] has quit [Quit: Bridge terminating on SIGTERM]
mvaittin has quit [Quit: Bridge terminating on SIGTERM]
RossSchulman[m] has quit [Quit: Bridge terminating on SIGTERM]
GooberMan has joined #beagle
argonautx has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
blathijs has joined #beagle
<blathijs>
Hey folks. Quick question: When I start up my BBB and run `gpioinfo`, I see that a lot of pins have e.g. "P9_12" in the "consumer" field of the gpio lines. AFAIU that field should show e.g. "kernel" or "sysfs" or whatever consumer value you pass when using libgpiod, but I can't quite figure out where this "P9_12" value comes from. Any pointers?
<blathijs>
(the underlying thing I'm trying to address is how to configure pin numbers from userspace for use with libgpiod, where resolving from a nice name like P9_12 would be nice, but it seems the actual GPIO name of that pin is GPMC_BE1N which is a bit less easy for users to figure out)
tbr has quit [Ping timeout: 272 seconds]
florian has joined #beagle
GooberMan has quit [Quit: Connection closed for inactivity]
<zmatt>
blathijs: the consumer of the gpio line is the gpio-of-helper device which exports the gpio via sysfs
<zmatt>
which is named via DT
<zmatt>
("sysfs" is the label used when _manually_ exporting gpios to sysfs from userspace)
<zmatt>
I use an udev rule to create symlinks for these sysfs exports (https://pastebin.com/raw/FVCkbDzt) so applications can directly access them by name, e.g. /dev/gpio/P9_12/value
<zmatt>
and in practice, rather than using cape-universal (which names the gpios after the expansion header pin and configures them as input-bidirectional), I use DT to name and configure gpios appropriate for the application, e.g. https://pastebin.com/YKW7Wcqu
<zmatt>
so that the application doesn't need to know or care where the signals it uses are physically located (allowing them to be easily relocated as part of a pcb revision when needed, with only a DT update required) and it ensures userspace cannot inappropriately change the direction of gpios
<zmatt>
(I don't use or care about libgpiod since it does not seem to support any of this)
Konsgn has joined #beagle
tbr has joined #beagle
<zmatt>
jkridner: heh, we just encountered a beaglebone which was shipped with eMMC contents so badly corrupted that the filesystem could not be mounted nor repaired by e2fsck
<blathijs>
zmatt: Ah, gpio-of-helper was the missing bit, I found it in the devicetree now. It's still a bit weird that the Pxx_yy names end up in the "consumer" field of the gpio, it seems gpio-of-helper passes the name as a label, but maybe that gets used as the consumer somewhere. Seems I'm also running an older image (kernel from 2019), so maybe things chnaged since then.
<blathijs>
In any case, thanks for the pointers :-)
<zmatt>
blathijs: note that normally a gpio can have only one consumer, i.e. gpio-of-helper would be mutually exclusive with libgpiod... rcn's kernels "solved" that by just patching out the gpio-in-use-check :P
<blathijs>
Ah, that explains, I was already wondering about that...
<rcn-ee>
zmatt, side note, gpiolib has a more complex 'gpio tracking' struct, so that hack is broken as of 5.8/5.9~ish.. i've just removed it for later kernels...
<rcn-ee>
(and gpio-of-helper for that matter is also removed..)
samael has quit [Ping timeout: 240 seconds]
xet7 has quit [Remote host closed the connection]
<zmatt>
rcn-ee: I guess I'll have to take a look at gpio-of-helper to forward-port it to later kernels, I do remember it looked like it could use some cleanup
<zmatt>
not a fan of using debugfs for something that isn't related to debugging the kernel, but I personally don't use bone-pinmux-helper
<zmatt>
though it's such a trivial driver there's little reason to not keep it
<zmatt>
also not really clear what these "pin groups' are
<rcn-ee>
for, us, we'd have to do a pin group for every gpio... "mmc_gpioX.." "mmc_gpioY"... essentialy config-pin but under debugfs...
<zmatt>
for every pin you mean
<rcn-ee>
yeah, pin...
<zmatt>
I don't think I like it... like, I don't know what the intended use of the "pin group" concept was, but I feel like it probably wasn't meant as a way to grant userspace access to mess with it
<zmatt>
having explicitly configured devices in DT is much better
<rcn-ee>
So without the gpio-of-helper patch, as long as we still have the same device-tree with all our pin groups that gpio-of-helper/config-pin used, this "pinmux-select" would allow swapping modes just like config-pin today.. the thing it doesn't do is the intial pin export that gpio-of-helper did..
<zmatt>
gpio-of-helper and bone-pinmux-helper are completely unrelated things
<rcn-ee>
sorry, yeah.. forgot there was two... i should try bone-pinmux-helper without gpio-of-helper on 5.13.x...
<zmatt>
neither has a dependency on the other
<zmatt>
pinmux-helper allows userspace to select a pinmux config from a set of mutually exclusive pinmux configs, as used by cape-universal to select between modes of one pin (though pinmux-helper is not constrained to that usage, you could have one device that swaps out between sets of pinmux for multiple pins)
<zmatt>
gpio-of-helper allows declaring the gpio you use, setup their (initial) config, and export (constrained) access to them via sysfs
<zmatt>
I consider gpio-of-helper a hard requirement for safe gpio access from userspace (gpiod is fundamentally poorly designed and not a usable alternative), so if noone has forward-ported it yet then I definitely will
<zmatt>
rcn-ee: ah, I see gpio-of-helper still uses the legacy kernel API for gpio, I'm guessing that's the problem?
<rcn-ee>
that's part of it...
<zmatt>
and what's even with these weird counters that nobody uses, and why does it assign ids
<zmatt>
(well, I assume nobody uses them, maybe I'm wrong)
<zmatt>
I can't even figure out how you'd read them from userspace
<zmatt>
also wtf happened to permissions in /sys/class/gpio ...
<zmatt>
rcn-ee: in Feb 2019 we had email contact about fixing some horrid udev rules (subject: "slow boot due to cape-universal"), and for a while things were good, but now it seems they're back to an even worse version
<rcn-ee>
ah crap..
<zmatt>
which actually change all files in /sys/class/gpio to be executable :/
<zmatt>
"80-gpio-noroot.rules: this broke in v5.4.x, use Pi s version"
<zmatt>
broke how?
<zmatt>
(the fix would be fixing it, not breaking it more)
<rcn-ee>
i'm looking, and i didn't reference that commit..
<zmatt>
my original rule is basically a not-awful version of "chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath" (%p is an abbreviation for $devpath)
<zmatt>
an udev rule shouldn't have to mess with anything *outside* /sys%p since that's stuff belonging to devices other than the one for which the udev rule triggered
<zmatt>
can I just safely install a 5.4-ti kernel on the 2020-04-06 image to see for myself what's going on, or will that break things? I guess I'll just try
<rcn-ee>
5.4 should be safe.. (minus uio overlays..)
<zmatt>
didn't I fix uio-pruss for some 5.x ?
<zmatt>
or was that 4.19
<rcn-ee>
4.19 and some of 5.x
<zmatt>
it's such a trivial driver, how did it break again
xet7 has quit [Remote host closed the connection]
<zmatt>
anyway, first things first
<rcn-ee>
btw, ti's merged a lot of remoteproc into mainline, so 5.10.x i've just been enable that by default as it loads pru firmware and runs..
<zmatt>
I mean, it's been enabled by default for a while now, but functionally it's still only a poor subset of uio-pruss
<zmatt>
as evidenced by the uio-pruss-shmem driver you guys made (which I mentioned is redundant: you can use the existing uio_pdrv_genirq driver to do exactly that)
<rcn-ee>
what is it really missing from uio-pruss? aka can we fix it to be more uio-pruss like?
xet7 has joined #beagle
<zmatt>
not without just making uio-pruss
<rcn-ee>
would like just one driver to make everyone happy..
<zmatt>
they're fundementally incompatible from a philosophical point of view... remoteproc is designed to give userspace as little access as possible, uio to give userspace as much access as possible
<zmatt>
with remoteproc the kernel performs loading (and only supports loading ELF executables), with uio userspace is responsible for loading and can therefore support any format it likes (py-uio supports both ELF and raw pasm binaries) or even use dynamic code generation if it feels like it (I use dynamic code modification for setting breakpoints in my debugging-example)
waldo323__ has quit [Ping timeout: 240 seconds]
<zmatt>
ah, I found where gpio-of-helper's counters can be read: cat /sys/bus/platform/devices/ocp:cape-universal/status ... I wonder if anyone actually uses that or if it could be safely dropped to simplify the driver
<mattb0ne>
or if you are getting side tracked fix the pin config workflow for the BBAI
<mattb0ne>
please with sugar on top
<zmatt>
isn't that lorforlinux's job? :P
<zmatt>
actually, isn't config-pin working now on the bbai?
<zmatt>
rcn-ee: as far as I can tell my original 80-gpio-noroot.rules seems to work fine on the 5.4-ti kernel, the permissions look the same as on 4.19-ti (as expected since nothing seems to have changed in /sys/class/gpio between those kernels)
<zmatt>
rcn-ee: one thing my rule doesn't cover that it maybe should is the export/unexport attributes, but that's not a breaking change in 5.4, it's been like that from the start... since cape-universal people don't generally manually export gpios anymore I think
<zmatt>
trying to manually export a gpio that's already exported actually makes it vanish
<zmatt>
(even though it wasn't originally exported via sysfs but by gpio-of-helper, and therefore userspace should not be able to unexport it)
<zmatt>
rcn-ee: if you want to allow group gpio to export/unexport, here's my suggested replacement 80-gpio-noroot.rules: https://pastebin.com/raw/Jut7431n
<zmatt>
I've already seen someone get confused by it
<zmatt>
which kernel release broke gpio-of-helper? or, which kernel series should I target for fixing/forward-porting gpio-of-helper, 5.10-ti ?
<zmatt>
(same question for uio-pruss)
<rcn-ee>
so 5.10-ti still has the gpio-of-helper hacks .. the 5.9.x-bone + has it all removed as i'm trying the mainline option..
<zmatt>
"hacks" :/
<rcn-ee>
for uio-pruss, both 5.4.x-ti and 5.10.x-ti it's broken..
<rcn-ee>
gpio-of-helper + my hacks. ;) is what i meant..
<zmatt>
gpio-of-helper could use some polish but it's an extremely useful driver
<zmatt>
the gpio chardev is _not_ a usable replacement as far I'm concerned
mattb0ne has quit [Ping timeout: 268 seconds]
<rcn-ee>
it really depends how a users use's config-pin... if they do "config-pin P9.12 spi", we can use the new interface under pinmux select: "pinmux-p9.12-spi-pins pinmux-P9.12" > pinmux-select .... but we need to conver all the config-pin cover cases..
<zmatt>
again you're confusing pinmux-helper and gpio-of-helper
<rcn-ee>
i should really seperate that patch into two. ;)
<zmatt>
yes you should, they do not belong together at all
<zmatt>
I'm also not a fan of the debugfs mechanism for changing pinmux... how does an overlay disable this mechanism for this pins it uses?
<zmatt>
or will the kernel not allow changing pinmux while in use by a driver?
<rcn-ee>
that's the number one problem...
<zmatt>
and it's just an abuse of debugfs... debugfs is meant for diagnostics, not for normal operation
<rcn-ee>
it's weird, how we "enable" all pins, then each overlay disables them from the config-pin list.. but with the pinmux-select, there's really no good way to remove "used pins" on each overlay load..
<zmatt>
how exactly are these pingroups declared anyway? I read the bindings for pinctrl-single and pinctrl-bindings... but it's not at all clear how the latter generic documentation even applies to pinctrl-single, and the pinctrl-single binding doesn't mention groups at all
<rcn-ee>
so... exactly how we do it today...
<rcn-ee>
our "cape-universal" massive pinmux list, works with pinmux-select...
<zmatt>
today we create a virtual pinmux-helper device for each pin which switches its pinmux state via the normal kernel api used by drivers to select a pinmux state for a device, and it simply gives userspace the ability to get/set that state
<zmatt>
also wait, pinmux nodes end up in groups automatically? so this debugfs mechanism gives userspace the ability to (try to) activate random pinmux nodes?
<rcn-ee>
so we could use: echo 'pinmux_P8_07_gpio_pu_pin pinmux_P8_07_gpio_pu_pin' > pinmux-select vs config-pin P8_07 gpio pu...
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<rcn-ee>
Correct, so with our current massive device-tree pinmux, these show up for under debugfs.. the new pinmux-functions select was added with pdp's git commit in 5.9/5.10 era..
<zmatt>
I guess it's debugfs so horrid stuff that breaks things if you look at it the wrong way is okay there, but I don't see why on earth you'd want to use this instead of bone-pinmux-helper (the "bone-" should really be removed from the name, it's completely generic)
<zmatt>
(also, those pinmux node names are an eye-sore, there's really no reason why they have such a verbose name instead of "P8_07-gpio_pu")
<zmatt>
like, right now the node name is more verbose than the node label (which has to be globally unique in the DT)
<zmatt>
P2_03_gpio: P2_03-gpio {}; is what I'd write
<drewfustini>
I added documentation for all the debugfs files
<rcn-ee>
zmatt, i can go with that..
<zmatt>
rcn-ee: right now it's purely cosmetic (e.g. shows up in show-pins)
<rcn-ee>
it would also show up under pinmux-select/function..
<zmatt>
right, which on current stable 4.x kernels is purely debug info
mattb0ne has joined #beagle
<zmatt>
drewfustini: how is using a debugfs mechanism that gives userspace the ability to mess with everything better than explicitly declared pinmux-helper devices in DT ?
<zmatt>
also, what do "group" and "function" mean in the context of pinctrl-single ?
<zmatt>
how do you configure these groups?
<zmatt>
why do these concepts exist when the normal consumers of pinctrl (drivers or the driver core framework) don't use them at all? pinmux-helper uses pinctrl_select_state() just like every other consumer
<zmatt>
in general I'm very much in favor of userspace access to pinmux control being limited to cases where such control is explicitly declared by DT
<zmatt>
(less important for debugfs, but debugfs is normally root-only for good reasons, and it shouldn't be necessary to poke around there as part of normal startup of a production system)
vagrantc has quit [Quit: leaving]
LetoThe2nd has joined #beagle
Shadyman has joined #beagle
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #beagle
vagrantc has joined #beagle
<drewfustini>
zmatt:
<drewfustini>
> how is using a debugfs mechanism that gives userspace the ability to mess with everything better than explicitly declared pinmux-helper devices in DT
<drewfustini>
The concept of bone-pimux-helper does not work as it creates a platform device for each pin. This was done because so that each pin could have a pinctrl state but it is not acceptable upstream.
<drewfustini>
pinctrl-single has a simple of mapping of 1-to-1 for pin function and pin group.
<zmatt>
it creates a platform device for userspace-controllable pinmux state, this may control one or more pins
<drewfustini>
it was not seen as a viable solution when i discussed it on linux-gpio
<zmatt>
it's a trivial driver to maintain out of tree
<drewfustini>
i don't want out of tree, i wanted an upstream solution
<drewfustini>
groups and functions are existing concepts in the pinctrl subsystem
<zmatt>
this mostly just gives the impression that upstream doesn't give a shit about this use case
<zmatt>
so if each pin function is in its own group, how exactly does this select one function out of the various mutually exclusive functions for a pin?
<drewfustini>
each node in am33xx_pinmux creates a pin function and pin group
<drewfustini>
`pingroups` will print all pin groups registered on the pin controller
<drewfustini>
those should be similar when pinctrl-single is used
<drewfustini>
`pinmux-functions` will print each pin function along with the pin groups that map to the pin function
<zmatt>
and you need to manually deselect the previously selected function before selecting a different one?
<zmatt>
since the kernel doesn't know how they're supposed to be grouped together
<drewfustini>
it calls pmxops->set_mux(). for pinctrl-single, that is pcs_set_mux
<zmatt>
as in, it just changes the mux instead of allowing the kernel to continue tracking the fact that the pin is in use (the way it normally works with pins used by devices)
<zmatt>
?
<drewfustini>
in pcs_set_mux(), each pcs_func_vals in the function will be activated
<drewfustini>
this is debugfs
<drewfustini>
there is no device for pinmux_select_state() to be called on
<zmatt>
is it just me or is this mechanism just really bad with upstream-acceptability being its only redeeming quality?
<zmatt>
it's just poking directly into pinctrl internals in a way that makes it definitely belong in debugfs, and definitely not belong being a normal part of startup of most beaglebones
<zmatt>
like, this is barely better than poking directly into the pinctrl registers via /dev/mem
<drewfustini>
there is no userspace api for pinctrl
<drewfustini>
this is a compromise
<drewfustini>
it is much better than that
<zmatt>
bone-pinmux-helper directly exports the pinmux_select_state() api to userspace
<drewfustini>
it only allows pinctrl functions and groups declared in DT to be activated
<zmatt>
which is a feature, not a bug
<drewfustini>
bone-pinmux-helper can never be uptreamed and I wanted an upstream solution
<zmatt>
a good out-of-tree solution with low maintenance load is better than a poor mainline solution
<drewfustini>
i disagree
<zmatt>
you're saying it doesn't matter if a solution sucks, if it's in mainline it's automatically better? yeah, then we indeed disagree
<zmatt>
like, mainline doesn't want a userspace api for pinctrl, cape-universal requires a userspace api for pinctrl... bone-pinmux-helper implements this cleanly, while adding a low-level debugfs mechanism that mainline tolerates because it's "just a debug mechanism" and then abusing that to accomplish the same thing in a worse way while mainline can pretend it's not happening... just doesn't sound like a ...
<zmatt>
...great situation
<zmatt>
does it at least refuse to change pinmux of pins that are in use by other kernel drivers?
<drewfustini>
It does not operate at that level. It just allows a pin group and pin function to be activated
<zmatt>
and what if the pin is already in use by a kernel driver?
<zmatt>
it will just not care and clobber the pinmux?
<drewfustini>
This interface makes no protection for that. The person using it would need to mitigate any problematic usage like that
<zmatt>
okay, this sucks so badly it's starting to sound like a joke
<drewfustini>
Well that is your opinion. Others on the list felt it was useful.
<drewfustini>
I am only interested in solutions that can be upstreamed
<zmatt>
are you taking over maintenance of the beagleboard.org kernels?
<zmatt>
if not, why do you care about the existence of bone-pinmux-helper in it?
<zmatt>
I'm pretty sure most users would prefer to keep a mechanism that already works well unchanged, and I feel confident that the maintenance of this driver can be taken care of. just like I'll be forward-porting/maintaining gpio-of-helper and uio-pruss
<mattb0ne>
I do not understand much of what has been discussed but I want something easy as a novice user of BBB and BBAI
<mattb0ne>
lol
<zmatt>
well I'm sure config-pin will continue to work in some way or another, though controlling pin config from software in a simple way like https://pastebin.com/MKtWJ8G8 will not be possible
<zmatt>
drewfustini: here's an idea: I've been meaning to try to see if I can get this upstream: https://github.com/dutchanddutch/bb-kernel/tree/am33x-v4.14/patches/drivers/uio some devices require some initialization to be done *before* pins are muxed, and when using a kernel driver that would be done with an "init" state or whatever it's called separate from "default" state, but that obviously doesn't ...
<zmatt>
...work with uio devices where the setup is done from userspace, hence this proposal for adding an ioctl to get/set the pinmux state of an uio device
<zmatt>
if upstream accepts that, you can just replace pinmux-helper devices by uio_pdrv_genirq devices (with no irqs or maps) :D
<drewfustini>
interesting, this does give a good use case for it
<drewfustini>
has there been any discussion of this on a kernel list?
<zmatt>
no, posting this to the appropriate list is still on my to-dos
<zmatt>
I'd also first want to re-check it and bring it in sync with mainline
<zmatt>
I also think using uio devices as replacements for pinmux-helpers would be pretty gross (but not quite as gross as the debugfs thing)
set_ has joined #beagle
Konsgn has quit [Read error: Connection reset by peer]
Estefa05 has joined #beagle
<Estefa05>
Hola!!
Estefa05 has quit [Client Quit]
<rcn-ee>
zmatt, considering uio hardly ever changes, and the gpio guys keep rewriting things, i like hte uio based pinmux-helper idea..
<zmatt>
rcn-ee: pinmux-helper has nothing to do with the gpio guys, and pinmux-helper's api has been stable (ignoring that some code used to make bad assumptions on how to find things in sysfs)
<zmatt>
the gpio sysfs interface has also been perfectly stable :P
<zmatt>
and you don't need to worry about finding gpios in sysfs if you add this udev rule that creates symlinks in /dev/gpio/ : https://pastebin.com/qZZmQQQg
<zmatt>
don't think so... assuming the permissions of export/unexport was the problem you were previously having with it
<rcn-ee>
i think that was... it's the only thing that makes sense..
<zmatt>
so the commit message was just mistaken about this being related to 5.x kernel
<rcn-ee>
i'm searching our slack archive, it was during my initial testing of v5.4.x-ti... Once your export the gpio is the actual gpio still root:gpio or is it root:root?
<rcn-ee>
(aka to set input/output, then high/low..)
<zmatt>
they get changed to root:gpio as soon as they appear (regardless of whether that's due to being initially exported by cape-universal or manually exported later)
<rcn-ee>
duh, but they properly change to root:gpio for our users to utilze directly...
<zmatt>
? ... I'm not sure what you're asking if it's not what I just answered
<rcn-ee>
zmatt, sorry, need more coffee, you stated what i wanted. ;)
LetoThe2nd has quit [Quit: Connection closed for inactivity]
vagrantc has quit [Quit: leaving]
<zmatt>
RossSchulman[m]: that looks like a wifi/bt-enabled microcontroller module you run your own software on, it's not clear to me that it can also be used to provide a linux host system with wifi/bt