ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
Lucanis has joined #armlinux
apritzel has quit [Ping timeout: 255 seconds]
sakman has joined #armlinux
alpernebbi has quit [Ping timeout: 240 seconds]
alpernebbi has joined #armlinux
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #armlinux
hanetzer has quit [Ping timeout: 244 seconds]
hanetzer has joined #armlinux
amitk has joined #armlinux
hanetzer has quit [Ping timeout: 240 seconds]
monstr has joined #armlinux
hanetzer has joined #armlinux
monstr has quit [Ping timeout: 258 seconds]
hanetzer has quit [Ping timeout: 245 seconds]
hanetzer has joined #armlinux
xvmt has quit [Remote host closed the connection]
xvmt has joined #armlinux
headless has joined #armlinux
smoothdev has quit [Ping timeout: 258 seconds]
smoothdev has joined #armlinux
<Xogium>
rfs613, jn: here's interesting development. I added wp-gpios to my dt node yesterday, and have been trying to figure out if it actually works as intended ever since -- i.e that it really brings it low when writing, and high when not, and that until I try to write something it is read-only
<Xogium>
unfortunately I am not able to confirm the status, at all. I don't know if it's read-write by default or not. I can't export the gpio anymore in sysfs given it's used by the kernel, and neither can I use gpiomon from gpiolib to monitor its activity
<Xogium>
I have not found how to confirm this
<jn>
gpioinfo (from libgpiod-tools) might be able to print the status
<Xogium>
sure, but not while writing :/
<jn>
ah
<jn>
ok, there are two tasks here:
<jn>
1. verify that the eeprom is protected before and after writes
<jn>
2. verify that the eeprom is unprotected during writes
<Xogium>
yep
<jn>
for 2, simply check that the writes go through
<Xogium>
yes I tested, they do go through
<jn>
for 1, gpioinfo should do the job
<Xogium>
but how do I run a write and gpioinfo exactly at the same moment ? This thing is rather fast for an eeprom
<jn>
or, if you don't want to trust gpioinfo and your understanding of the gpio line, maybe initiate a eeprom write with the i2c userspace tools
<jn>
Xogium: you don't need to run a write and gpioinfo at the same time
smoothdev_ has joined #armlinux
<Xogium>
but then how will I know which status it has when writing vs which one it has when not writing ?
smoothdev has quit [Ping timeout: 258 seconds]
smoothdev_ is now known as smoothdev
<jn>
if the write went through, you know that the eeprom was unprotected during the write, which is the desired state
<Xogium>
yes, but I don't know that it then turns back to read-only
<jn>
ok, that's question 1 again
<jn>
and for question 1 you don't need to look at it during the write
<Xogium>
sorry, I'm just confused
<Xogium>
when it's not writing, it's showing like this in gpioinfo
<Xogium>
line 12: "PF12" "wp" output active-high [used]
<Xogium>
which to my brain means it's not protected
<jn>
hmm
<Xogium>
but I don't know for sure
<jn>
i don't see the state in that line
<jn>
which means that gpioinfo doesn't seem to provide enough information, sadly
<Xogium>
well, output and active_high, isn't that the state ?
<jn>
no, it can still be asserted (high) or deasserted (low)
<jn>
which is the interesting part
<Xogium>
but I'm honestly confused by gpiolib either way because when I did my manual testing with sysfs then checked with gpioinfo, setting the like direction to output and not touching active_low, it displayed exactly like that, yet read-write was allowed as expected. Replicating the same thing with gpiolib, that is, setting to output and leaving active high was not working
<Xogium>
and of course sysfs won't work anymore
<jn>
active-high only means that 1 (active, asserted) corresponds to high (3.3V or whatever)
<jn>
active-low only means that 1 (active, asserted) corresponds to low (0V, GND)
<jn>
active-high doesn't mean that the GPIO is currently asserted
<Xogium>
right... In the case of this eeprom, if you pull to gnd it allows writes
<jn>
ok, then active-high seems alright for the WP pin (active = protected)
<Xogium>
same if left floating but that one you shouldn't do because it's undefined state and with all the noise, well
<Xogium>
I can't believe debugging gpio is that difficult tbh
<Xogium>
it should be easier to determine if it works as intended or not
<jn>
not exactly undefined, but i'll quote the atmel datasheet directly: "If the pin is left floating, the WP pin will be internally pulled down to GND. However, due to capacitive coupling that may appear during customer
<jn>
applications, Atmel recommends always connecting the WP pins to a known state. When using a pull-up resistor, Atmel recommends using 10kOhm or less."
<Xogium>
yes
<Xogium>
didn't explain that good I guess
<Xogium>
board has a 10k resistor connected to it too
<Xogium>
I guess really, what confuses me the most is that with sysfs, all I need to do is alter the direction. Change in to out, and it allows writing. Change back to input again, and writing is blocked. Which is how the gpio is displayed initially when *not* configured as a wp-gpio
<Xogium>
that is, input
<Xogium>
unfortunately I lost my only trusty debug method when enabling wp-gpio, so I can't even check on its state or direction at all in sysfs
nsaenz has quit [Quit: Leaving...]
<jn>
i don't know how to sniff GPIO traffic done by kernel drivers
<Xogium>
and there gpiolib worked differently. To get this to work in gpiolib I had to invert the polarity and make it active_low then passing 1. Which... Okay, that's already confusing in itself because in active_low 1 means 0
<Xogium>
that is, setting to output with 1 wasn't enough
<jn>
but active-low is objectively wrong for the WP pin
<Xogium>
then gpiolib stuck that 1 there until I rebooted. No way to go back to a 0
<Xogium>
I wish gpio wasn't such a headache :D
<jn>
and i don't know what "pass" means here
<Xogium>
setting state from 0 to 1 basically
<jn>
i.e. pass = "set value to"? ok
<Xogium>
yeah like gpiochip5 12=1
<Xogium>
or 12=0
<jn>
ah, alright
<jn>
and active-high, value=0 didn't unprotect the eeprom?
<Xogium>
but as far as I understand, passing 1 when active-low == passing 0 when active-high
<Xogium>
nop, that's protection
<jn>
why?
<Xogium>
0 is input
<Xogium>
1 is output
<Xogium>
when you boot linux, gpioget will definitely tell you 0, and gpioinfo will still mention active-high
<jn>
that seems wrong, i'd expect gpioset to work in output all the time (unless some open-drain stuff is configured)
<Xogium>
and that 0+active_high == write protect
<Xogium>
in sysfs, switching direction to out is good enough. It also makes the gpio appear as output active-high in gpioinfo
nsaenz has joined #armlinux
<Xogium>
gpioget can't be used there, but I do suspect it would return 1
<jn>
no no no. the at24 datasheet says, that WP is active high. i.e. active (1) enables protection. inactive (0) disables the protection
<Xogium>
setting direction back to input and unexporting from sysfs shows 0 again in gpioget
<Xogium>
well
<jn>
gpioset foo 123=0 should do just the right thing to allow writing, unless there's a bug somewhere else
<Xogium>
I suspect gpioinfo is reporting crap, along with gpioget
<Xogium>
because I really see a 0 when it is write protected
<Xogium>
see why I'm confused ? :D
<Xogium>
sysfs behaves differently to gpiolib to the point I can't make sense of what the hell is going on
<jn>
gpioset foo 123=0 not unprotecting the eeprom is indeed confusing and something i can't explain
<jn>
ah, maybe you need -m signal or similar
<Xogium>
I mean, I suppose doing gpioset -l 5 12=1 would == gpioset 5 12=0, since it flips around
<jn>
as gpioset only promises to "maintain the state until the process exits"
<jn>
Xogium: ah, have you tested that?
<Xogium>
but then when gpioset terminates, for example on sigint, the gpio remained in output state, returned to active-high instead of active-low, and... The eeprom remained read-write
<Xogium>
at least, according to gpioinfo and gpioget
<jn>
ah ok, the termination behavior seems related to my latest suspicion (use -m)
<Xogium>
oh I did
<Xogium>
-m signal
<Xogium>
then when I was done, terminated it
<Xogium>
I expected it to go back to 0, active-high
mripard has joined #armlinux
<Xogium>
instead it stayed 1, but flipped active-low for active-high, and left the thing read-write instead of blocking the writes
<jn>
it goes back to undefined
<jn>
according to the manpage
<jn>
so you can't expect anything
<Xogium>
well, that's just plain dumb. Why make a gpioset tool if you end up having undefined behaviors with it ?
<jn>
i can't answer that, i haven't dug into the design history of it
<Xogium>
specially since the tool claims it is supposed to reset the gpio to its default when terminating, but then instead says undefined behavior ?
mripard has quit [Remote host closed the connection]
<jn>
ok, sorry, "undefined" was my interpretation, but "default state" really doesn't define it all that more precisely either
<Xogium>
yeah
<Xogium>
that tool is just ugh
<Xogium>
I honestly can't make sense of it
<jn>
the tool itself is just the surface
<jn>
most of the design and quirks come from the underlying gpio chardev interface, i suspect
<Xogium>
probably
<jn>
anyway, i don't think the gpio rant leads to much
<Xogium>
tbh sysfs is just that much simpler to work with. I mean sure you got to figure out the gpiochip number but this isn't much of a problem since you have a neat label file that tells you gpiof for example
<Xogium>
export the one you want, set direction to output and it just works, y'know
<jn>
it is unfortunate that you have to keep a process around to keep the state set, with the new API
<jn>
agreed
mripard has joined #armlinux
<Xogium>
it makes it very dumb because you end up having to run one process to set to output, then another to set to input unless you want to reboot between each single use of gpioset
<Xogium>
which is really, really, not practical
* jn
scratches head
luispm has joined #armlinux
<Xogium>
who knows, maybe one day sysfs will no longer be obsolete and chardev is the one that will get deprecated
<jn>
in the meantime, just reenable sysfs, it's not removed yet
<Xogium>
yeah I have it
<Xogium>
I was hoping to use it to debug gpio state, but then realized you can't. Hah
<Xogium>
at least when said gpio is assigned to something
<Xogium>
damn exclusive access
sszy has joined #armlinux
<jn>
anyway, my other idea for testing that the eeprom is protected most of the time was to initiate eeprom writes from userspace, using the i2c-dev interface. the "eeprog" program seems to do just that, so i'd propose two-step plan: 1. without any driver touching the eeprom or WP GPIO, verify that eeprog can write correctly. 2. with the eeprom driver and wp-gpios hooked up, check that eeprog can't write anymore
mvaittin has quit [Ping timeout: 258 seconds]
<Xogium>
yeah that's a good idea
<Xogium>
might be our oly way at this point tbh
<jn>
and it's less confusing and this more reliable than the gpio route, at this time
<Xogium>
yes
rockosov has quit [Ping timeout: 244 seconds]
headless has quit [Quit: Konversation terminated!]
rockosov has joined #armlinux
mvaittin has joined #armlinux
nsaenz_ has joined #armlinux
monstr has joined #armlinux
nsaenz has quit [Ping timeout: 264 seconds]
<Xogium>
jn: well, that's unfortunately quite unconclusive. I asked eeprog to read the first 6 bytes of headecimal on i2c0, address 0x50, starting at 0x0. It can't open the eeprom for reading
<Xogium>
*hexadecimal
mripard has quit [Remote host closed the connection]
<Xogium>
my guess is the eeprom driver or nvmem, or, something blocks eeprog from using the device
apritzel has joined #armlinux
monstr has quit [Ping timeout: 240 seconds]
monstr has joined #armlinux
prabhakarlad has joined #armlinux
<jn>
Xogium: was that step 1 or 2?
<Xogium>
test 2
<Xogium>
must be some exclusive access somewhere and it just chokes on it
monstr has quit [Ping timeout: 240 seconds]
<Xogium>
jn: I brought the hammer. Or maybe at this point we should say electric drill. Kernel tracing for gpio:* events and i2c writes
<Xogium>
but it's insane you have to resort to this lol
<jn>
nice
<jn>
i always forget that this tracing infrastructure exists
<Xogium>
so do I
<Xogium>
but it's a damn good thing it does
<robmur01>
Xogium: for "what state is the pin currently in?" questions, /sys/kernel/debug/gpio is your friend
<Xogium>
robmur01: hah I thought that was exclusive access too
<Xogium>
for some reason
<robmur01>
nope, it even tells you which pins are claimed or not
<Xogium>
ah, looks like I'm lacking the config option that shows this directory under debugfs
<Xogium>
good to know
<Xogium>
sysfs ftw then heh ? I might actually entirely remove gpio chardev from my system tbh
<robmur01>
of course there's still a chance that *that* doesn't match reality either, but that's the point when you need to go debugging the DT or the drivers themselves :)
<Xogium>
yeah
<Xogium>
tracing was really neat though. I just had to figure out how to do it
mripard has quit [Remote host closed the connection]
deathcamel57 has joined #armlinux
rgallaispou has left #armlinux [#armlinux]
<rfs613>
Xogium: hi, just seeing this now.. didn't read the whole thread.. but could you use a multimeter/scope/logic analyzer to look at the testpoint for the WR signal?
<Xogium>
rfs613: not really... Scopes/multimeter when you can't see are not exactly easy to use not to mention they don't really talk
<Xogium>
rfs613: I just wanted to know that I had basically set up the wp-gpio correctly. I ended up using kernel tracing to see it changing state while writing, because I of course lost access to sysfs and I also don't trust the output of gpioinfo and friends
<rfs613>
Xogium: I guess you could directly read the GPIO pins using something like 'devmem 0x12345678'
<Xogium>
hmm I hadn't tried that
<rfs613>
but it would be hard to catch it at the right time, if it only toggles briefly.
<Xogium>
yeah it's very fast
<Xogium>
toggles multiple times during a write using dd
<rfs613>
how long does it take to write the whole device?
<Xogium>
hmm... 2 seconds or there about
<rfs613>
well you might be able to catch it toggling in that case. But it's certainly not ideal ;-)
<Xogium>
nah huh
<Xogium>
kind of wish sysfs wasn't blocked so I could have checked up on it from there too
<rfs613>
yeah, sometimes the kernel is just too helpful...
<Xogium>
yeah, a bit too helpful indeed
<rfs613>
and yet, we can still dd all over a block device that's mounted, without any warnings, even after all these years ;-)
<Xogium>
yep !
<Xogium>
I did it once. It led to... Rather interesting results, to say the least ;)
smoothdev has quit [Read error: Connection reset by peer]
amitk_ has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 245 seconds]
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 255 seconds]
headless has quit [Quit: Konversation terminated!]
apritzel has joined #armlinux
smoothdev has joined #armlinux
apritzel has quit [Ping timeout: 258 seconds]
hanetzer has quit [Ping timeout: 246 seconds]
hanetzer has joined #armlinux
ezulian has quit [Ping timeout: 258 seconds]
prabhakarlad has joined #armlinux
amitk has quit [Ping timeout: 258 seconds]
<ukleinek>
robher: in 20230922211737.GA3628801-robh@kernel.org, what are "older clients"? If a machine is booted with a kernel that doesn't support = <3>?
heat has quit [Remote host closed the connection]
heat has joined #armlinux
smoothdev has quit [Quit: smoothdev]
heat has quit [Remote host closed the connection]
<robher>
ukleinek: older OS or other consumer of the DT