jwillikers has quit [Remote host closed the connection]
jwillikers has joined #u-boot
redbrain has quit [Ping timeout: 255 seconds]
akaWolf has quit [Ping timeout: 255 seconds]
akaWolf has joined #u-boot
Forty-Bot has quit [Ping timeout: 268 seconds]
Forty-Bot has joined #u-boot
redbrain has joined #u-boot
redbrain has quit [Ping timeout: 265 seconds]
akaWolf has quit [Ping timeout: 265 seconds]
akaWolf has joined #u-boot
pavelow has quit [Quit: No Ping reply in 180 seconds.]
pavelow has joined #u-boot
milkylainen_ has quit [Ping timeout: 255 seconds]
<sjg1>
marex: If you put the nodes in the other order it works. In fact if you search for /axi it will match any node since the @ is not needed. So make sure the 'least specific' node is first
<sjg1>
BTW just 'u-boot -D' will use the default DT and -T will use the test one. You don't need to specify the filename explicitly
<marex>
sjg1: so the suggestion is "u-boot is broken, fix your legacy DTs" ?
<marex>
sjg1: because this exact case is in zynqmp.dtsi in linux 5.10.y
<marex>
sjg1: if I try to apply a DTO on it, it fails because it tries to patch the axi@0 node instead of axi node, and I would argue THAT is a bug
<marex>
so no, no fixing of existing DTs, this is u-boot bug and should be fixed there
<marex>
robher also confirmed the DT is valid
<marex>
counter-intuitive, maybe, but valid
mthall_ has quit [Ping timeout: 255 seconds]
<sjg1>
marex: You should probably discuss it on the dtc mailing list. The function you are complaining about is fdt_path_offset() I think:
<marex>
(as far as I can tell, correct me if I'm wrong)
mthall has joined #u-boot
PoroCYon has left #u-boot [#u-boot]
<sjg1>
marex: It seems OK so long as you don't actually care which node you find. But I think axi should go before axi@0 and it is odd to have one node with a unit address and another, with the same name, without
<marex>
sjg1: robher said it is odd, but not wrong
<marex>
sjg1: and modifying valid DT seems like a workaround
<marex>
sjg1: I would expect that the node order shouldn't matter and that we should find exactly the node we want, not some other one, else it is a bug
<sjg1>
You are not able to specify which node you want, if you have the same name with and without the unit address
<sjg1>
I suggest telling Rob about it and then he might change the order and add it to his validator
<marex>
sjg1: /axi@0 and /axi seem pretty much clear to me
<marex>
sjg1: I talked to him about it yesterday already in #armlinux
<sjg1>
See also the DT spec: A unit address may be omitted if the full path to the node is unambiguous.
<sjg1>
This seems like a corner case. I think Rob will understand that if you give him the above info
<marex>
"if the full path to the node is unambiguous" ... it seems my English skill is just not good enough
<sjg1>
axi and axi@0 mean that 'axi@0
<marex>
well, no, look at the DT, they are two separate nodes
<marex>
with separate address and size cells even
<marex>
they describe the same bus though
<sjg1>
I *think* it means that if you have axi and axi@0, then searching for 'axi@0xxx is ambiguous
<marex>
sjg1: I would buy that argument if I was searching for axi, maybe, but axi@0 is pretty much non-ambiguous
<marex>
it is exactly that, axi@0 , there is no other option
<marex>
sjg1: but that;s why I poked robher here
<sjg1>
marex: did you look at fdt_nodename_eq_() ?
<marex>
sjg1: no, I am busy with multiple other things and cannot task-switch now
<sjg1>
marex: That's OK marek I'm just sitting on my hands! Anyway you have an easy fix and a path forward
<marex>
sjg1: I remember, you meantioned that before
<marex>
sjg1: the path forward is pretty clear, fix it myself and send patches
[[[R]]] has joined #u-boot
<sjg1>
marex: what is 'it' ?
<marex>
sjg1: u-boot or libfdt picking the wrong node when clearly told which node to pick
<sjg1>
Yes, as I said, take it up on dtc. An excellent way to do that is with a patch
<sjg1>
marex: It is definitely a corner case that could use a test either way
<marex>
sjg1: I will be blunt -- whenever I look at the u-boot tests, I just turn around and walk away
<sjg1>
I mean the dtc tests. They are in the dtc repo. We don't have them in U-Boot
<marex>
sjg1: what it misses is a good intro into "this is how you write your test, this is how you execute it" and not the usual "blah, read the .gitlab-ci.yml and figure it out yourself"