mzvd has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
goliath has joined #openwrt-devel
ekathva has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
csharper2005 has joined #openwrt-devel
rua has quit [Remote host closed the connection]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
rua has joined #openwrt-devel
csharper2005 has quit [Quit: Page closed]
csharper2005 has joined #openwrt-devel
<csharper2005>
rmilecki: thank you! it didn't occur to me that other archs might have own conflicting patches. ipq806x
<rmilecki>
csharper2005: sure, please check if anything is missing
<rmilecki>
csharper2005: also I find it a really bad idea to push commit that we know to break things just to have it fixed in following changes
<rmilecki>
csharper2005: users may not notice that, probably buldbots won't neither
<rmilecki>
but it breaks e.g. bisecting which is really important for me when looking for regressions
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
<csharper2005>
rmilecki: Should I have done 1 big squashed commit with all of the changes including fix routerboard patch? the way you did it... Instead of splitting them into main commit and fixes. Right?
<rmilecki>
csharper2005: multiple commits are OK and are often a good thing (if you introduce a big feature touching a lot of code) - that makes reviewing simpler
<rmilecki>
csharper2005: if your commit has a bug however - fix *that* commit
<rmilecki>
so fixes should be "fixup"s
<rmilecki>
multiple commits for easier review = good
mzvd has quit [Read error: Connection reset by peer]
<rmilecki>
nbd: it's bisected already, how to proceed?
<rmilecki>
should that mt76 commit just get reverted? should we send a revert patch?
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
<mrkiko>
nbd: and, talking about powersave, I am one of the users expriencing mt7622 wi-fi hang with iPhones / iPads probably due to powersave. Is this a know issue?
<mrkiko>
nbd: already running mt76 from openwrt master
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
rsalvaterra has joined #openwrt-devel
srslypascal is now known as Guest2601
srslypascal has joined #openwrt-devel
Guest2601 has quit [Ping timeout: 480 seconds]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
robimarko has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
<mrnuke>
nick[m]1234: Thanks! I was looking over that. Doesn't really answer my confusions about libubox/libubus APIs
<nick[m]1234>
maybe look into the git sources?
<mrnuke>
Yup, that's the last resort.
<mrnuke>
Is there a reason all my ubus_* and runqueue* data structures have to be declared "static " or else segfault?
guidosarducci has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
<xdarklight>
hauke: ping
mzvd has quit [Ping timeout: 480 seconds]
mzvd has joined #openwrt-devel
<mrkiko>
mrnuke: you should be able to use them even with malloc / free
csharper2005 has joined #openwrt-devel
<mrnuke>
mrkiko: I declare them as variables in my main(), so they don't fall out of scope
<mrnuke>
I had an idea to see if they get placed in .bss and are automagically zero0initialized as static
<mrkiko>
mrnuke: that's entirely posible. But if you malloc them and memset or bzero them you should have no issues
<mrkiko>
of course you'll be more knowledgeable in C than me, so of course you will have to pay attention to the & operator
<mrkiko>
I remember it strike me sometimes
<mrnuke>
Do you want me to pre-fill the structs? Do you want me to use helpers to initialize structs? macros? That's the sort of stuff that only API docs can anser (and not the Doxygen type)
<mrnuke>
As far as the & operator, think of it as giving the finger operator :p
<mrnuke>
It's the pointing finger, not the middle finger, but still a catchy way to think of it
csharper2005 has quit [Remote host closed the connection]
<hauke>
xdarklight: pong
guidosarducci has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
<xdarklight>
hauke: long time no see - I hope you are fine!
<xdarklight>
hauke: I have a couple of questions (as always ;)) and I am hoping that you have some answers or hints for me. first topic is https://github.com/openwrt/openwrt/issues/9829 - it seems that at some point (I suspect it's with the 5.10 kernel update) HH5A someone got a random reboot issue
guidosarducci has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
<xdarklight>
hauke: HH5A will hang up randomly. but what's also interesting is that it can hang during boot - typically while initializing the ath9k card. this hang is not always reproducible, but I've seen my test HH5A bootloop for 30 minutes or so. this however only happens with an image on NAND - I am unable to reproduce it with the same build using the initramfs image. that's why I believe that a combination of NAND + PCI causes it (disabling PCI
<xdarklight>
and booting from NAND has always worked for me: the problem is not reproducible in that case)
<xdarklight>
hauke: do you have an idea how this could all be related (do my thoughts make sense)?
<hauke>
xdarklight: I was bussy the last few weeks
<hauke>
PCI and NAND are sharing some resources in the SoC
<hauke>
PCIe is independent
clandmeter5 has joined #openwrt-devel
<xdarklight>
resources means internal bus?
c0sm1cSlug_ has joined #openwrt-devel
zarzarzar_ has joined #openwrt-devel
Piraty_ has joined #openwrt-devel
c0sm1cSlug_ has quit []
c0sm1cSlug_ has joined #openwrt-devel
tomn_ has joined #openwrt-devel
DLange_ has joined #openwrt-devel
aiyion_ has joined #openwrt-devel
guidosarducci has quit [reticulum.oftc.net liquid.oftc.net]
minimal has quit [reticulum.oftc.net liquid.oftc.net]
aiyion has quit [reticulum.oftc.net liquid.oftc.net]
Piraty has quit [reticulum.oftc.net liquid.oftc.net]
c0sm1cSlug has quit [reticulum.oftc.net liquid.oftc.net]
minimal has joined #openwrt-devel
fieryeagle954[m] has quit [reticulum.oftc.net liquid.oftc.net]
sorinello has quit [reticulum.oftc.net liquid.oftc.net]
clandmeter5 is now known as clandmeter
f12 has joined #openwrt-devel
takimata has joined #openwrt-devel
swegener has joined #openwrt-devel
sorinello has joined #openwrt-devel
owrt-2203-builds has joined #openwrt-devel
StifflersMagic has joined #openwrt-devel
tmn505 has joined #openwrt-devel
xes__ has joined #openwrt-devel
FLD has joined #openwrt-devel
blogic has joined #openwrt-devel
kabel has joined #openwrt-devel
Borromini has joined #openwrt-devel
guidosarducci has joined #openwrt-devel
BKPepe has joined #openwrt-devel
eloy__ has joined #openwrt-devel
MatMaul[m] has joined #openwrt-devel
Harm_ has joined #openwrt-devel
Q__ has joined #openwrt-devel
nick[m]1234 has joined #openwrt-devel
zatwai has joined #openwrt-devel
will[m]1 has joined #openwrt-devel
paper_ has joined #openwrt-devel
PaulFertser has joined #openwrt-devel
fieryeagle954[m] has joined #openwrt-devel
enyc has joined #openwrt-devel
niyawe has joined #openwrt-devel
whatevs111[m] has joined #openwrt-devel
grift has joined #openwrt-devel
robje has joined #openwrt-devel
John[m]12345678910 has joined #openwrt-devel
lemmi has joined #openwrt-devel
omni has joined #openwrt-devel
mzvd has quit [Remote host closed the connection]
mzvd has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
<hauke>
xdarklight: I looked into the documentation and it only mentions that some pins are shared
DLange_ is now known as DLange
<hauke>
there shuld be some HW which can switch as far as I understood it
<hauke>
but I am not an expert in this part of the HW
<xdarklight>
hauke: pins like the ones connected to the NAND chip (and also PCI bus)?
<hauke>
yes
<xdarklight>
oh, then it makes sense why it's called EBU: external bus unit
<hauke>
yes it can run arbitary busses
<hauke>
and it has some extended support for parallel NAND
<hauke>
it handles a up to 26 address lines and up to 16 data lines
<hauke>
xdarklight: we try to lock the PCI bus with the ebu_lock too
<xdarklight>
hauke: so this means: 1) either the PCI controller is configured incorrectly 2) the NAND controller is configured incorrectly 3) EBU is configured incorrectly 4-n) a mix of 1-3
<xdarklight>
hauke: you mean the lock in ltq_pci_config_access ?
<hauke>
I assume that the nand cotroller and the PCI controller are accessing the bus at the same time
<hauke>
and then we run into problems
<hauke>
xdarklight: yes ltq_pci_config_access() takes the same lock as the NAND controller
<hauke>
maybe they are accessing without taking the lock now
<hauke>
I think somehow the HW should also be able to handle the switching, but I haven't read and understood the full section yet
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
AtomiclyCursed has joined #openwrt-devel
<xdarklight>
hauke: ifxmips_pci_ops.c from source-files-FRITZ.Box_7490-06.80/linux-3.10: https://pastebin.com/Q5uHiECw - it doesn't take any EBU lock (doesn't mean that the upstream driver is not at fault though, just saying that it doesn't seem to be strict requirement)
<hauke>
the EBU should be abdle to do the endianess switching for between NAND and CPU
<hauke>
ok, we should have a look how AVM volved this
<xdarklight>
0xa matches what the AVM driver does: they OR together IFX_PCI_CLK_CTRL_EBU_PCI_SWITCH_EN = 0x2 and IFX_PCI_CLK_CTRL_FPI_NORMAL_ACK = 0x8
<xdarklight>
huh, are there two NAND controllers in xRX200 and later? or is it just that they added DMA transfers on top of the original NAND controller? the AVM code has ifxmips_mtd_dmanand.c (only used on "VR9" and "AR10") as well as ifxmips_mtd_nand.c (used on all SoCs)
<hauke>
mybe blogic added the lock becasue of some endianess swapping issues
<xdarklight>
intel-nand-controller seems to be for a (slightly?) different "HSNAND" core. https://pastebin.com/cqRwedfu is arch/mips/include/asm/mach-lantiq/vr9/vr9.h from source-files-FRITZ.Box_7490-06.80/linux-3.10 - some registers seem similar but some are totally different (for example: IFX_RX_CNT seems to be gone in the new IP)
<xdarklight>
I think I need to look into the NAND driver more. so far I've been looking into the PCI controller driver but couldn't find any significant differences. maybe because I'm searching at the wrong end of EBU
Tapper has quit [Ping timeout: 480 seconds]
<xdarklight>
also some google search for ifx_hsnand shows that AVM uses this driver on newer boards. porting intel-nand-controller over to xRX200 won't be easy since it means that we need a proper DMA engine driver first (drivers/dma/lgm/lgm-dma.c is already upstream, but as one would expect the IP in LGM and xRX200 has changed)
<hauke>
yes there are big differences between the vr9 and the lgm IP blocks in DMA and also the EBU
<hauke>
there are more than 10 years between these generations and multiple SoC generations
<hauke>
if the locking in the NAND driver is done to workaround some endinaness problems we can maybe configure the swapping somewheer else.
<xdarklight>
hauke: do you see somewhere which "chip select" PCI / NAND uses? at this point in time we configure NAND to be CS1 on HH5A - not sure if this is correct or whether there's some recommendation which CS to use when
<hauke>
the CS should be wired from a pin of the SoC to a pin on the flash chip
<xdarklight>
to me this looks like some muxing inside EBU
<xdarklight>
but maybe ultimate you're right: if EBU can take two sets of NAND chip-selects then this may end up just changing the external signal
<hauke>
the EBU in vr9 supports 4 CS
<hauke>
but it depends where the wire to the flash chip is connected to
goliath has quit [Quit: SIGSEGV]
<xdarklight>
I'll fully compare the EBU setup in xway_nand with the UGW code but it looks fishy: UGW either uses LTQ_EBU_BUSCON0 or LTQ_EBU_BUSCON1 depending on "CS0" or "CS1". also we're not initializing LTQ_EBU_BUSCON1[15:14]. that's two differences I spotted... so I think it's worth digging further
Borromini has quit [Ping timeout: 480 seconds]
<xdarklight>
hauke: thanks a lot so far - I'll see what I can do on the next rainy day :-) fingers crossed though that we can find something there
<hauke>
if you found more details about the problem please send me a mail
csrf has quit [Quit: Leaving]
<hauke>
xdarklight: the GSWIP uses the fid == = as a default setting
<hauke>
I am not sure if using it somewhere intentionally will cause problems
<hauke>
If a static MAC forwarding is configured for the CPU port using the MAC address of one of the LAN ports which is not in a bridge we should use the prot speicfic mac address
<xdarklight>
hauke: ok, so then the question is: which FID can we use if we want to target the CPU port. I can make it (CPU port + 1) but I am not sure how the matching with GSWIP_TABLE_MAC_BRIDGE's key works internally
<xdarklight>
the first patch has the goal of being backported to 5.15. the second one will go into whatever next LTS kernel we have
<hauke>
xdarklight: ok, if you do not know from which port the mac address is using fid 0 could be fine
<xdarklight>
regarding GSWIP_TABLE_MAC_BRIDGE: the key consists of the MAC address (makes sense) and the FID. if we use let's say FID = 8 (CPU port + 1) how does the hardware know that let's say an incoming packet on port #3 matches FID 8? I'd expect the hardware to look up all the FIDs that port #3 is part of and then try with all found FIDs + MAC
<hauke>
you should check that the GSWIP does not forward packets where it should not
Borromini has joined #openwrt-devel
<xdarklight>
yep, I can check that
<xdarklight>
do you know if GSWIP hardware can tell us if a packet has been targeted to the CPU because it's supposed to get there (MAC table) or just because it didn't know and is now flooding the packet to the CPU?
<hauke>
xdarklight: I think it does not has such a bit
<xdarklight>
that would've been too nice :)
<xdarklight>
to sum up the GSWIP topic: basically you're not against FID 0 as long as it doesn't result in packets leaking to other ports
<hauke>
yes
<hauke>
please test this with and without VLAN filtering activated
<xdarklight>
noted, will do
<xdarklight>
thanks again hauke! :)
Borromini has quit [Quit: leaving]
mrnuke has quit [Remote host closed the connection]