warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
niska has quit [Server closed connection]
niska has joined #u-boot
mmu_man has joined #u-boot
polprog has quit [Server closed connection]
polprog has joined #u-boot
frieder has quit [Remote host closed the connection]
rgallaispou has quit [Remote host closed the connection]
rgallaispou has joined #u-boot
warpme has joined #u-boot
<Tartarus>
Community call in 3min
clamor has quit [Ping timeout: 260 seconds]
monstr has quit [Ping timeout: 256 seconds]
slobodan has joined #u-boot
clamor has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
ellyq has quit [Server closed connection]
ellyq has joined #u-boot
mmu_man has quit [Ping timeout: 245 seconds]
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
mmu_man has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
averymt has joined #u-boot
averymt has quit [Client Quit]
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
ikarso has quit [Quit: Connection closed for inactivity]
swiftgeek has joined #u-boot
Jones42 has quit [Ping timeout: 258 seconds]
Jones42 has joined #u-boot
Jones42 has quit [Client Quit]
Rutherther has quit [Server closed connection]
Rutherther has joined #u-boot
mmu_man has quit [Ping timeout: 256 seconds]
ldevulder has quit [Ping timeout: 256 seconds]
mmu_man has joined #u-boot
ldevulder has joined #u-boot
Poltawer has quit [Quit: WeeChat 4.7.1]
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 260 seconds]
rvalue- is now known as rvalue
clamor has quit [Read error: Connection reset by peer]
ldevulder has quit [Ping timeout: 258 seconds]
mmu_man has quit [Ping timeout: 258 seconds]
mmu_man has joined #u-boot
ldevulder has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
mmu_man has joined #u-boot
prabhakalad has joined #u-boot
ikarso has joined #u-boot
<shadows>
Tartarus: I missed the call, all I might have to say is that the regression with LwIP DNS is still a problem, and there's a patch posted that resolves the functional problem but I disagree with the symbol names proposed.
prabhakarlad has quit [Ping timeout: 258 seconds]
<shadows>
that might have been more helpful to say in the call but I was busy
<Tartarus>
shadows: Can we perhaps fix the problem for now and do more aggressive symbol renaming in next?
<shadows>
fine by me
<shadows>
I complain about a lot of things, admittedly.
<shadows>
the thing is that I know I'm on to something because there's a mutually exclusive DHCP issue and something else, patches posted adding "CMD" config symbols because stuff is broken without bringing in the more obscure symbol names that actually provide support without bringing in the commands themselves
<shadows>
it's just confusing is kind of my point and difficult to search for in the code base, what are all the "network" related things? who knows. You can't learn it just by searching "NETWORKING" in the config for example.
<shadows>
Tartarus: more holistic question, are we at a milestone yet where renaming "classic" 'net' to i.e. legacynet would be considered along side the new lwip stuff
<Tartarus>
No, not yet
<Tartarus>
And yes, a general problem that we've only solved in some cases is that we used to have a lot of CMD_FOO means FOO and also the cmd for FOO
<shadows>
ah. yep
<Tartarus>
In some cases, we do mean CMD_FOO because it's still a better idea in some cases to construct a cmd string and call it, rather than try and use an API
<Tartarus>
I think this ends up being one of those cases, in the EFI_LOADER part?
<shadows>
unsure, but yes I did see those symbol names on a brief poking around to construct what I wrote about that, loosely, it could be better and easier to read from an overview or grep having not any previous knowledge about the code base
<shadows>
at least some of the EFI symbol names make an effort to be descriptive. I lose my patience when people obsess over abbreviating things
<shadows>
that historical context you mention is helpful to know, thanks
<shadows>
Tartarus: what is that first search pattern for -u-boot.dtsi override is it the dts file itself? I don't quite understand it at scripts/Makefile:200
<shadows>
at least for what I'm doing in the warning output printed it evalates to "-u-boot.dtsi" so that did not give me any contextual clue what is the purpose of it
<shadows>
documented at develop/devicetree/control.rst:209 found it!
<shadows>
well that seems broken, or the warning output is broken, I guess.
<Tartarus>
shadows: er, it shouldn't evaluate out to "-u-boot.dtsi" that should be the one that would catch for example th1520-lichee-pi-4a-u-boot.dts for th1520-lichee-pi-4a.dts
<shadows>
Tartarus: ha! that's not what I see in my build output. Interesting.
<Tartarus>
Which rule does?
<shadows>
a moment, I'll dig into this, with better description of what I'm seeing
<shadows>
firstly the 'make starfive_visionfive_defconfig' run https://paste.debian.net/1393593/ which probably could benefit from some molly guarding of undefined things so we don't evaluate to "-u-boot.dtsi" minor nit I guess but it would be helpful to instead say that something was not found rather than go on
<shadows>
"Automatic .dtsi inclusion: options: " and then a bunch of paths that are meaningless and not found, that is not useful information. Open for suggestions about how to implement such a thing, I'm weak on Makefile knowledge
<shadows>
Tartarus: at a guess what I'm seeing is that because the targets are OF_UPSTREAM and the dts filenames are derived from CONFIG_OF_LIST so they're not real Makefile targets, they don't show up in that search
<shadows>
that is a ... bug ?
<shadows>
or a feature.
<Tartarus>
Shouldn't be a change?
<Tartarus>
Or it's a bug
<Tartarus>
Double check how it works on non-OF_UPSTREAM
<shadows>
ah, for starfive_visionfive2 non-OF_UPSTREAM would have been back in hmm... v2025.01?
<shadows>
Tartarus: confirmed, at least for the 'make' after. obviously the 'make starfive_visionfive_defconfig' is the same output none of those things get defined.
<Tartarus>
I mean, you can just hack things up a bit to test :)
<shadows>
arch//dts/-u-boot.dtsi and then to riscv/dts/-u-boot.dtsi ...
<Tartarus>
Well, as an aside I wonder if riscv is broken in some way, but that's only because I'm still unhappy about the whole fdt_addr=0xfffffff thing there
ikarso has quit [Quit: Connection closed for inactivity]
<Tartarus>
But the dtb files to be built are always part of dtb-y, in the end, OF_UPSTREAM, or not
<Tartarus>
yes?
<Tartarus>
(handling of .dtbo is it's own issue, lets set that aside)
<shadows>
what's a defconfig you know handy that I could try for a look at how it is supposed to work
<shadows>
I have not ventured outside of the starfive_visionfive2 stuff yet
<shadows>
or the other way, if you want to try, from origin/master:
<shadows>
make DEVICE_TREE_DEBUG=1 O=$HOME/build/u-boot -C $HOME/source/u-boot.git starfive_visionfive2_defconfig
<shadows>
make DEVICE_TREE_DEBUG=1 O=$HOME/build/u-boot -C $HOME/source/u-boot.git