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
heat has quit [Ping timeout: 260 seconds]
nsaenz has joined #armlinux
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #armlinux
haritz has quit [Read error: Connection reset by peer]
mvaittin has joined #armlinux
mvaittin_ has joined #armlinux
mvaittin has quit [Ping timeout: 260 seconds]
bjoto has joined #armlinux
<Xogium>
I do have to honestly say that I really dislike the yaml documentation and much prefered when the doc was actual plain text
<jn>
the yaml devicetree bindings?
<Xogium>
yes
<Xogium>
makes it hard to understand for my brain
<jn>
it came to me in a dream that someone had written scripts to convert them into HTML, but i'm not sure if that ever actually happened
<Xogium>
honest, txt, html, either would be better than darn yaml
<Xogium>
trying to figure out this nvmem wp gpio business
<Xogium>
I still don't understand how that works. What happens if you set a wp gpio ? How do you control when it's write protected or not ?
<mvaittin_>
I thought I am the only one who has problems with the yaml ;) I'd really be in problems if krzk and rob weren't so helpful.
<Xogium>
am I meant to still toggle it manually in sysfs ?
mvaittin_ is now known as mvaittin
<Xogium>
mvaittin: nah, somehow it's really hard to parse for my neurodivergent brain. Blindness might have a role to play in it too for me
<jn>
Xogium: looking at drivers/nvmem/core.c, it's briefly deasserted when writing to the nvmem
<jn>
and the binding indeed doesn't say that — it only describes the hardware relation, not how the linux driver makes use of it
<Xogium>
jn: ah, I see. So read-only all the time except when you actually want to write stuff
<jn>
yep
<jn>
although, as far as i understand the code, the driver won't actively set the write-protect upon initialization
<jn>
if the bootloader left the nvmem unprotected, linux will leave it unprotected too, until the first write
<jn>
so that might be something to watch out for
<Xogium>
ah the gpio's input/active high initially
<Xogium>
if I toggle direction to out using sysfs I can then write to the eeprom
<Xogium>
toggle back to in and it's blocked again
<Xogium>
yeah I uses sysfs because gpiolib seems to have a bug somehow
<Xogium>
once I toggled to output using gpioset, I can't ever unset it again
<Xogium>
except with a soft reboot
<Xogium>
worse, behavior from sysfs and gpiolib differ in that to make it work with gpiolib I have to pass -l to gpioset then output on top. With sysfs I just set it to out as direction and active_low always remains at 0
<jn>
what's -l?
<Xogium>
active_low
<Xogium>
inverting polarity
<Xogium>
fun part is once it's terminated, the active_low become active_high again, but it is stuck as output
<jn>
hmm, i see
<Xogium>
so the eeprom becomes read-write until I reboot, basically
<Xogium>
think I'll stick with the sysfs interface. Annoying a bit to figure out the gpiochip number and so on, but at least it works as you'd expect
<jn>
but when you tie up the WP GPIO with the nvmem driver directly, you should be able to sidestep all of these problems
<Xogium>
yeah
<Xogium>
linux is in fact already considering it as nvmem. I just have to implement dt related things
<Xogium>
it's just that yesterday was very confusing... First realzing the vendor did a mistake in the dt and set to a 4 kbytes eeprom not a 32 kbytes one like the schematics has, then realzing the weird errors like connection timeout were because it was read-only
<Xogium>
then hitting this gpiolib issue
<Xogium>
oof
<jn>
hmm, 32 kbits. memory vendors like stating sizes in bits
<Xogium>
yes
<Xogium>
the schematics said at24c256
<Xogium>
dt was at24c32
<jn>
ah i see
<Xogium>
I guess they got confused there too, somehow
monstr has joined #armlinux
<Xogium>
thing I'm unclear about is how do I tell linux in the nvmem that the target is the eeprom ?
<jn>
the nvmem node *is* the eeprom, as far as i understand it
<jn>
otherwise, i need to see the relevant part of your DT
<Xogium>
oh
<Xogium>
because currently, the way seeed did it is they simply made a dt node eeprom@0x50 on i2c1
<jn>
sounds good
<Xogium>
so I must define the nvmem inside that node, correct ?
<jn>
no
monstr has quit [Ping timeout: 246 seconds]
<jn>
you can use the nvmem properties (specifically wp-gpios) in the eeprom node
<jn>
no additional node
<Xogium>
huh, really ?
<jn>
seems so
<Xogium>
well apparently wp-gpio has been removed for eeprom directly since the nvmem subsystem handles it
<Xogium>
rfs613 found a commit referencing that yesterday, let me check
<Xogium>
they've just forgot to edit all documentation telling you that you can do it
<jn>
at24.yaml says: use the nvmem binding too ($ref: /schemas/nvmem/nvmem.yaml)
<Xogium>
so they've somehow converted it ?
<jn>
(i don't understand how these /schema paths work, but nvmem.yaml seems clear enough)
<Xogium>
but I need to make use of nvmem things I think. I use this eeprom to store 2 mac addresses and want linux to retrieve different mac for eth1 and eth2 from it
<jn>
the driver can still be buggy, but the binding says you can use wp-gpios
<Xogium>
u-boot is currently duplicating ethaddr on both interfaces instead of picking eth1addr and eth2addr
<jn>
so, that's currently not working on the linux side?
<Xogium>
more like not implemented :) I'm trying to figure out what I need to do to have this. I understand how to retrieve the nvmem in the eth1 and eth2 nodes, but adding the nvmem is where I struggle with
<jn>
AFAIUI: the at24 eeprom node is a nvmem node, use it as such. there's no separate nvmem node
<Xogium>
eth1 and eth2 need to grab a nvmem cell each
<Xogium>
so for instance I need to tell it yeah the eht1 addr starts at @0 and has 0x6 byte length, eth2 starts at 0x10 and has the same 0x6 length
<Xogium>
afaik
<Xogium>
not sure if I'm making sense here
<jn>
what i don't understand is simply what's holding you up
<jn>
in other words, "yeah, just go ahead and do it"
<Xogium>
I don't understand how I must define those cells, I guess. And where
<jn>
you need two things:
<jn>
1. an nvmem producer (your eeprom node that you have)
<jn>
2. the properties that consume the nvmem bits, as your ethernet binding dictates
<Xogium>
right but 2 refers to cells with a phandle that doesn't exist. I mean, this is how it is currently done -- at the moment the dt tries to grab a mac address from the OTP on the board, but it is empty. And it is is literally calling a phandle defined all the way down in stm32mp131.dtsi
<Xogium>
where st defined the efuse
<jn>
ok, and instead of the OTP memory you want to use your eeprom?
<Xogium>
yes
<jn>
do that
<jn>
change the phandle reference in the ethernet property
<Xogium>
but how ? I don't understand where I must define the phandle I then refer to in the second step
<jn>
show me the code
<Xogium>
I have no cells defined at all.. Hmm, sec let me give you the dt I currently have
<Xogium>
what I have trouble picturing in my mind is how to do the same with the eeprom
<jn>
ok, i suspect that you can create the same kind of nvmem cells under the eeprom node: 1. add #address-cells and #size-cells, as you're probably gonna need them; 2. add mac1 and mac2 with the right addresses
<Xogium>
hmm so inside the eeprom node
<jn>
just like inside the efuse node
<jn>
i haven't tried it, but that's what i expect
<Xogium>
is there a good way to figure out the number for adress cell and size cells, anyway ?
<Xogium>
that's one particular point of dt I always struggled with
<jn>
they're required to be 1 by nvmem.yaml
<Xogium>
ah, well, one less thing to worry about... I remember struggling a lot with pwm attached buzzer and being like ugh how the hell do I figure out cells for this thing
<jn>
how nvmem cells work seems to be defined in nvmem-cells.yaml
<jn>
hmm, no. that's weird stuff
<jn>
related to defining nvmem cells inside MTD partitions
<jn>
fixed-cell.yaml it is
<jn>
and nvmem.yaml has examples
<jn>
anyway, you had the examples already, in the efuse node
Grimler has quit [Ping timeout: 255 seconds]
iivanov has joined #armlinux
<Xogium>
yeah I just tend to get overwhelmed quick, sorry about that :/
<jn>
that's ok, this stuff is confusing and yaml-based bindings have a lot of "look elsewhere"
<Xogium>
yeah, gah
Grimler has joined #armlinux
_jannau_ has quit [Ping timeout: 255 seconds]
<Xogium>
hopefully this will work
<jn>
fingers crossed
iivanov has quit [Remote host closed the connection]
<Xogium>
this port sure wasn't easy to do but I'm glad I managed it
<Xogium>
it wasn't porting to mainline, just to upstream vendor so st, but still. It was a pain to do because seeed certainly made it difficult, with no documentation at all
headless has joined #armlinux
iivanov has joined #armlinux
<Xogium>
well the good news is compilation went well. That's at least a good sign :D
sszy has joined #armlinux
<Xogium>
jn: it works ! Linux now has 2 different macs
<jn>
very nice!
<Xogium>
if I could do the same with u-boot, now too, that'd be great... I did the same stuff as with kernel, enabled config_nvmem and... It's somehow not getting the data and insists eth1 and eth2 have no address set
<Xogium>
must be missing a config ;)
apritzel has joined #armlinux
Grimler has quit [Ping timeout: 258 seconds]
<Xogium>
ah yes CONFIG_I2C_EEPROM :)
luispm has quit [Ping timeout: 255 seconds]
Grimler has joined #armlinux
<Xogium>
oh... Huh
<Xogium>
u-boot is really working differently. I told that eth1 has mac1 and eth2 has mac2, but for u-boot this leads to eth1addr having mac2 and ethaddr having mac1
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
prabhakarlad has joined #armlinux
headless has quit [Quit: Konversation terminated!]
Saalim has joined #armlinux
<Saalim>
hi
luispm has joined #armlinux
Grimler has quit [Ping timeout: 260 seconds]
Grimler has joined #armlinux
Saalim has quit [Read error: Connection reset by peer]
pg12 has quit [Remote host closed the connection]
pg12 has joined #armlinux
Saalim has joined #armlinux
strudl has quit [Ping timeout: 255 seconds]
strudl- has joined #armlinux
haritz has joined #armlinux
haritz has quit [Changing host]
haritz has joined #armlinux
sakman has joined #armlinux
sakman_ has joined #armlinux
sakman has quit [Ping timeout: 244 seconds]
prabhakarlad has quit [Quit: Client closed]
heat has joined #armlinux
rgallaispou has joined #armlinux
mripard has left #armlinux [#armlinux]
mripard has joined #armlinux
mripard has quit [Quit: mripard]
mripard has joined #armlinux
iivanov has quit [Quit: Leaving]
sakman_ is now known as sakman
Saalim has quit [Ping timeout: 246 seconds]
Saalim has joined #armlinux
Saalim has quit [Read error: Connection reset by peer]