<Ansuel>
board.json in theory is never touched and is not carried with config backup
<Ansuel>
board.json is touched by uci-defaults scripts
<Ansuel>
these 2 assumption are correct?
<Ansuel>
ok just confirmed with a just egenrated backup that board.json is not included by default (and I don't think anyone would include it)
<Ansuel>
also this problem is only with realtek switch so in theory anything that use ext4 (aka not overlay) should not be affected/ should not have the entry
<Ansuel>
So in theory we can just change every entry of network-device to network_device and fix netifd to detect that
<Borromini>
well it looks like realtek is the only target 'exploiting' that feature
<Ansuel>
none of this should use ext4 and everyone should be overlay based
<Ansuel>
Soo IMHO the correct approach is 2 patch. One fix config_generate and the other fix netifd...
<Borromini>
ok :)
<Ansuel>
main problem is how to handle the regression on stable...
<Ansuel>
MHHHH
<Borromini>
PR 13622 (against main) has the netifd patch incorporated - author is aware it won't get merged like that - but that worked for me on 23.05 HEAD
<Borromini>
all my realtek devices just got their MACs back after a regular sysupgrade with the patched netifd
<Ansuel>
yes cause board.json is generated from scratch everytime after a sysupgrade
<Ansuel>
this is fixable but i need to hear hauke on suggestion on how to handle this...
<Ansuel>
do we have an idea of the amount of broken devices?
<Borromini>
all realtek devices, basically.
<Ansuel>
(For sure SNAPSHOT can be restored as soon as the image are rebuilt)
<robimarko>
Basically, fix this and the ramips wlan eeprom
<robimarko>
And make a quick 23.05.1
<Borromini>
Ansuel: 23.05.1 should be as easy as sysupgrading as well, if incorporated
rua has left #openwrt-devel [#openwrt-devel]
rua has joined #openwrt-devel
<Ansuel>
just a bit upset of not noticing this in 4 rc :(
<Ansuel>
robimarko what about ramips wlan eeprom ?
<Borromini>
Ansuel: lots of bug reports flying around I suppose ;)
xback has quit [Remote host closed the connection]
xback has joined #openwrt-devel
valku has joined #openwrt-devel
<robimarko>
Ansuel: The Unifi 6 WLAN not working after conversion to NVMEM
<Ansuel>
but that is on snapshot or it's stable?
<robimarko>
Oh you are right, that should be snapshot only
<Borromini>
thanks Ansuel :)
<Ansuel>
robimarko i just merged the revert commit... saddly that wifi chip require cal and precal like ath10k but that wasn't pointed out and it was asked to use only eeprom
<Ansuel>
and IMHO it would be stupid to have one cell and use offset instead of declaring 2 cell and use the offset directly in DT
goliath has quit [Quit: SIGSEGV]
Borromini has quit [Quit: Lost terminal]
<Ansuel>
I wonder if precal-eeprom would be good to use?????
sepf has joined #openwrt-devel
<rmilecki>
Ansuel: oh, hey, I just saw revert and was going to ask you about that precal
<rmilecki>
i'll take a look at it too
<Ansuel>
I don't like using offeset in nvmem cell and I think that would be rejected upstream. For precal a reorg of the way precal is handled is needed (to keep compat with mtd and other)
<rmilecki>
I was sure nbd said that internal layout is always the same and we can just point to the whole data blob
<rmilecki>
i'll have to did it out
<rmilecki>
my memory may fail me
<rmilecki>
*may be failing me
<mrkiko>
am I exhagerating or - in the future, a lot of ipq4xx evices are going to break due to kernel size limit?
Mangix has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
mentalow has quit [Quit: :]]
mentalow has joined #openwrt-devel
Danct12 has quit [Remote host closed the connection]
<Ansuel>
yep really need nbd hint cause precal on mt7915 is fully bugged... unless i'm missing something the values are never loaded???
<cmonroe>
is precal only failing on mt7981 (or mt7986 or mt7916) based devices like the u6-lite? e.g. mt7915 devices like the E8450 and friends are ok?
Danct12 has quit [Quit: A-lined: This user has been AVIVA-lined!]
<Ansuel>
they added support for declaring an offset
<Ansuel>
but then on the acrual read it's never handled and just ignored and override with
<Ansuel>
offset = be32_to_cpup(list);
<Ansuel>
that is the offset of the partition passed in DT
<Ansuel>
offset should have been +=
<Ansuel>
but it's =
<schmars[m]>
nice find
<Ansuel>
actually this is the quick fix i can backport... and then i will take care of rework all this mess since with the nvmem implementation this is a mess
<Mangix>
Ansuel: OTOH they have the hardware. my understanding is that even if the code is broken, it allows everything to work
<Ansuel>
Mangix thanks for asking... i was desperately trying to find a way to create a cheap and easy patch for backport since code avolved a lot and it's hard to backport...
<Mangix>
hmm?
<Ansuel>
Mangix... nothing just you asking made me think of a better way to create the patch series
<Ansuel>
I can now rework the code without caring for backport
<Mangix>
In other news, I asked ChatGPT to explain and english patch diff and it summarized it as Correção de compilação do GCC7.
<Mangix>
I don't even
<Ansuel>
AI is massively good for asm parsing and explaining tho
<Ansuel>
I abused it for PCRE to PCRE2 conversion... but you always have to put a little of correct brain for the thing to actual work
<Ansuel>
it's more of a boosted hint than actual solution for a problem
<Mangix>
oh yeah, code conversions need to be double checked, but it tends to do it 90%
<Ansuel>
i don't want to know the wall text the thing wrote
<Ansuel>
also did you tried bing? (chatgpt4 + web)
<Mangix>
no. I only use bard and ChatGPT. is bing free?
<Ansuel>
yes
* Mangix
looks
<Ansuel>
bing.com/chat
<Mangix>
I asked it to explain split phase like I'm 5. This explanation is useless.
<Mangix>
It’s like having two different pipes that bring water to your house, but the water in one pipe is always moving in the opposite direction of the water in the other pipe. <-- what?
rmilecki has quit [Quit: Konversation terminated!]
mkrle has joined #openwrt-devel
<Mangix>
Ansuel: if I'm reading that right, the latest commit needs to be reverted again and those specific devices be handled
<mkrle>
qq regarding NVMEM changes - I have a PR open to add support for a new mt7621 device and I've updated it yesterday to support the NVMEM format (mt7603+ mt7615). Am I right reading that only a few mt7915 are getting reverted and that I should keep the changes in my PR?
<Mangix>
mkrle: yes
<mkrle>
or not :)
<Mangix>
it
<Ansuel>
ok you don't need to repeat
<Mangix>
's probably mt7915 and newer
<Ansuel>
Mangix actually that commit will have to be changed with the precal nvmem
<Mangix>
right
<mkrle>
Mangix: ty!
<Mangix>
for that dlink and ubiquiti devices
<Mangix>
/s//that/those
<Mangix>
fff
<Ansuel>
'
<Ansuel>
?
<Mangix>
I failed to disable GRO/GSO
Tapper has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
aiyion has quit [Remote host closed the connection]
<Ansuel>
from swconfig i can see everything is connected to eth0
<Ansuel>
ag71xx 19000000.eth: connected to PHY at mdio.0:1f:00 [uid=004dd042, driver=Qualcomm Atheros QCA9561 built-in PHY]
<Mangix>
eth1 is not present
<Ansuel>
yes and we were using eth1 as cpu port
<Ansuel>
and we are defining stuff in the eth1 mdio node
<Ansuel>
swconfig was probably working as it does try to find the thing? or it wasn't using DT at all
<Mangix>
interestingly enough, the datasheet lied
<Mangix>
this is an ar9344 switch, not ar9331
<Ansuel>
swconfig say switch0: Atheros AR8229 rev. 1 switch registered on mdio.0
<Ansuel>
lol
rmilecki has joined #openwrt-devel
<Mangix>
mdio0 suggestion did not work
<Ansuel>
nothing changed in the log?
<Mangix>
from the earlier DSA failures, no
<Mangix>
both mdio0 and eth0 changes are no go
<mirko>
can somebody help me with CONFIG_NF_TABLES_SET ? i can't find this symbol neitehr in linux upsream, nor within openwrt, except that a package NF depends on tries to package net/netfilter/nf_tables_set.ko which doesn't exist (and AFAIS can't be built)
<mirko>
though the module is referenced since 2020 in include/netfilter.mk, so i'm probably jsut missing something
<mirko>
ah, the moduel/symbol is only found in Linux kernels: 4.18–4.20, 5.0–5.6
<mirko>
so not anymore in 5.15 / 6.1 what openwrt currently suppors - still wonder why nobody else runs into the same issue, though
<Mangix>
Ansuel: finally got something: ag71xx 19000000.eth: connected to PHY at !ahb!eth@1a000000!mdio!switch@1f:04 [uid=004dd042, driver=Qualcomm Atheros QCA9561 built-in PHY]
<Ansuel>
? what did you change?
<Mangix>
phy-handle = <&swphy4>; from 0
<Mangix>
and status = okay for eth1
<Ansuel>
are we sure the bit is getting applied???
<Mangix>
addr swap? I didn't change it
<Ansuel>
yep but i wonder if it was swconfig that apply it
<Mangix>
no
<Mangix>
ag71xx
<Ansuel>
same compatible or eth1 with the original one?
<Mangix>
original
<Mangix>
i removed the compatible
<Ansuel>
ok
<Mangix>
now time to see if I can even pass traffic through this
<Ansuel>
for sure it's getting detected
<Mangix>
The switch is AR9344 AFAIK, which the driver doesn't support
<Ansuel>
so the switch have comunication with the gmac
bluew has joined #openwrt-devel
hitech95 has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
<hurricos>
Ansuel: I have a powerpc turris I still haven't unboxed :c
<hurricos>
Mangix: got the initramfs for me? :^)
<hurricos>
I'll just flash it actually, I gotta open the case anyways
<hurricos>
where in sweet heaven did I put my pile of mx60s
<hurricos>
ah geez I bet they're back at the hackerspace