<guidosarducci>
Great, just wasted more of my time trying to test 21.02 using IB, and traced it to dnsmasq-full builds failing for ath79 in 21.02-SNAPSHOT. Looks like someone was playing with $(FPIC) and broke the libnfnetlink dependency.
<ynezz>
rmilecki: you should build with CONFIG_BUILDBOT=y in order to reproduce the failures locally
<rmilecki>
ynezz: first I had problem finding error in that long log
<rmilecki>
but got it finally
<rmilecki>
ynezz: do you think it would make sense to build using "make -j $FOO V=s|| make V=s" ?
<rmilecki>
ynezz: so after failing build with multiple threads, a next attempt it made with single thread
<rmilecki>
and so error is easy to find
<ynezz>
IIRC we've discussed this already, it makes sense, patches are welcome :)
<rmilecki>
ynezz: possibly, i could forget
<rmilecki>
ok, thanks
<rmilecki>
FWIW: ERROR: module '/builder/shared-workdir/build/build_dir/target-aarch64_cortex-a53_musl/linux-bcm4908_generic/linux-5.4.109/drivers/crypto/ccp/ccp-crypto.ko' is missing.
<ynezz>
while at it, it might probably make sense to use similar approach as in phase2/packages, thus build with BUILD_LOG=y and do `make -jMAX || make -j1 V=s`
Namidairo has quit [Ping timeout: 265 seconds]
Namidairo has joined #openwrt-devel
<guidosarducci>
mangix: Huh? You're expecting that error? Based on what analysis? And why do you think it's an issue with bpftools package and not your build system, or your latest test GCC? Can you be more forthcoming and clear? Otherwise I doubt I can help you. Post your analysis, troubleshooting, steps to reproduce, etc somewhere and I'll try to look later, but need to run now.
<rmilecki>
jow: hey, i'm looking for a way to use "uci" cli in 2 isolated contexts
<rmilecki>
jow: both -p and -P seem to *add* new delta path
<rmilecki>
jow: so if my old app code uses /tmp/.uci and new one uses "uci -P /tmp/.foo" i still have that one look in /tmp/uci
<rmilecki>
jow: should (and could) I add uci cli option for using exclusive delta path?
goliath has joined #openwrt-devel
AAAA has joined #openwrt-devel
AAAA has quit [Client Quit]
victhor has joined #openwrt-devel
ashkan has quit [Ping timeout: 240 seconds]
ashkan has joined #openwrt-devel
<karlp>
wb9688: how do you even keep track of that many? are most of them just every private message ever?
silverwhitefish has quit [Quit: One for all, all for One (2 Corinthians 5)]
<rmilecki>
aparcar[m]: uh, copying all config files sounds a bit hacky
<rmilecki>
well, not all
<rmilecki>
but still sounds a bit hacky
embargo has joined #openwrt-devel
<rmilecki>
nbd: can you tell me, why do we do that? https://git.openwrt.org/?p=project/uci.git;a=commitdiff;h=cd2883daece34b501ef5e8f5c764fbb162f3aef4 ("cli: don't commit, if the savedir was overwritten")
Radu-Mamy has joined #openwrt-devel
<nbd>
rmilecki: because the savedir override is for overlays
<nbd>
that should not be commited into the main config
<rmilecki>
nbd: does it mean i shouldn't use -P for my case? can you see my description up in IRC log?
<nbd>
i guess i still don't fully understand your use case
<nbd>
so you want a separate confdir and a separate savedir that behaves like normal uci, but does not touch /etc/config at all?
<rmilecki>
no separated confdir
<rmilecki>
I want 2 apps to operate on the same /etc/config/ set of files
<rmilecki>
both apps use uci CLI tool
<nbd>
but once you commit to /etc/config, it'll be visible to the other one as well
<rmilecki>
i want each of app to stash their changes independently
<rmilecki>
right, that's expected
<nbd>
so i guess you need to change uci to add a flag like -P which does not set the nocommit flag
<rmilecki>
1. UI app does "uci set system.hostname=foo" *without* commiting - let'ssay that change is *not* ready to be commited
<rmilecki>
2. Bash script does "uci set system.timezone=UTC; uci commit system" - that will commit changes of UI app
<rmilecki>
nbd: yes -P without CLI_FLAG_NOCOMMIT woud work for me I beleive
nitroshift has joined #openwrt-devel
<rmilecki>
(i don't want bash app to accidentally commit UI *pending* changes)
zatwai has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
zatwai has joined #openwrt-devel
embargo has joined #openwrt-devel
kristrev has joined #openwrt-devel
<kristrev>
Hi. I got my hands on an mt7622 board that I would like to try to port OpenWrt to. I am not very familiary with the platform, are there any recomended places to start or resources to look at?
<kristrev>
I have found and looked at Daniel Golles work for E8450, so I have a rough idea of where to start
<kristrev>
Tha board is running a really old version of u-boot, so my goal includes replacing the bootloader
<Ivan__83>
kristrev: you should create dts file and add your dev to 02_network
<Ivan__83>
and in .mk
<Ivan__83>
this is minimal things to do to get working openwrt on device
<kristrev>
Thanks. I have added support for a couple of other boards, so I am aware of that step. I am not so familiar with mt7622 or arm, so I would like to try to do some research before I head too far in the wrong direction :)
<enyc>
hrrm .. at least one of my Lantiq xrx20 HHv5a OpenWRT is rebooting itself .....
<enyc>
intermittent problem with candelatech firmware, maybe
<enyc>
I'm going to have to get the router I have TTL serial debug attached to, back in service, test older Master build, test updated 21.02SNAPSHOT, monitor ........
<clayface>
Basically it is working nicely as is incl VLAN with DSA drivers. Apart from name and using the different DT to the 5301x platform, the b53 swconfig driver isn't 58xx or Serdes compatible which is needed. ar8216 would also need modified to work with b53 vlans even if both the former were fixed.
<rmilecki>
clayface: it's on my list to look at it
<rmilecki>
clayface: right after uci & failing bcm4908
<Zero_Chaos>
the fix for my issue turned out very simple, I hit another issue which I bet is the same. I'll fix the other similar issues and post a patch in a few
<Zero_Chaos>
it's just quotes on the right line of the makefile
<Zero_Chaos>
nevermind, new issue is different
<Zero_Chaos>
Package iptables-nft is missing dependencies for the following libraries:
silverwhitefish has quit [Quit: One for all, all for One (2 Corinthians 5)]
<Hauke>
Zero_Chaos: guidosarducci: libnfnetlink is fixed again
Tost has joined #openwrt-devel
<Zero_Chaos>
Hauke: thanks!
blogic_ is now known as blogic
jas4711 has quit [Ping timeout: 252 seconds]
junland has quit [Quit: %ZNC Disconnected%]
junland has joined #openwrt-devel
<Hauke>
xdarklight: should we wait till the next 5.4 stable release to merge the DSA changes?
<xdarklight>
Hauke: I think yes, we should wait. mkresin has patches for 5.10 (as testing kernel version) in his tree already. that way I don't need to duplicate the backports but we simply wait for the next stable release
Night-Shade has joined #openwrt-devel
<Hauke>
xdarklight: are the problems still seen xrx300 related?
<xdarklight>
Hauke: yes no and maybe. there's this crash log from Aleksander from xRX200: https://pastebin.com/A01Hj6aY (I have never seen this before)
<xdarklight>
Hauke: then there's some people reporting problems with the FritzBox 5490 (xRX200) - I have no idea there yet, I didn't speak with the owner of that device yet
<xdarklight>
Hauke: and then there's various xRX300 issues on which you have commented
<Hauke>
hmm the crash log from Aleksander loks strange
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Borromini has left #openwrt-devel [#openwrt-devel]
PaulFertser has quit [Ping timeout: 246 seconds]
<xdarklight>
Hauke: just out of curiosity: is the GPHY firmware executed in-place? meaning: we need to have a dedicated chunk of DDR memory for each GPHY instance (like we do have right now) or is only the code in RAM but the "work area" is somewhere in internal SRAM?
PaulFertser has joined #openwrt-devel
philipp64 has quit [Quit: philipp64]
philipp64_ has joined #openwrt-devel
<Hauke>
I think it is executed in place
kristrev has quit [Read error: Connection reset by peer]
hbug___ has quit [Ping timeout: 240 seconds]
hbug___ has joined #openwrt-devel
kristrev has joined #openwrt-devel
rmilecki has quit [Ping timeout: 240 seconds]
<xdarklight>
Hauke: makes sense, I think that's the straight forward way to implement it
ashkan has quit [Ping timeout: 240 seconds]
dedeckeh has quit [Ping timeout: 240 seconds]
<xdarklight>
Hauke: this is the PHY11G (and PHY22F) initialization code from AVM: https://pastebin.com/dYbN1S9B - note line 267 and following. they're using a 200ms delay after asserting the reset line and also a 200ms delay after deasserting it. also they re-try multiple times if the PHY shows up on the MDIO bus
<xdarklight>
Hauke: compared to that we're currently missing the 200ms delay after asserting the reset line in the lantiq_gswip.c driver. our deassert delay is 300ms so we should be fine there. also we don't implement any retry logic, but I'd avoid that if possible...
<xdarklight>
Hauke: I also found some file in UGW which also uses a 200ms delay: ifxmips_vr9_gphy.c
<Hauke>
xdarklight: it looks AVM uses 500ms before and after releasing the reset
<xdarklight>
Hauke: funky, they use different delays in the same driver...
<Hauke>
looks like they wrere experimenting and at some time it worked ;-)
<xdarklight>
Hauke: so from that guy on the pull request with my 200ms delay patch: "This seems to have at least fixed the first problem! After about 15 router reboots, I haven't seen the inicialization error once"
<guidosarducci>
Hauke: Appreciate the quick turnaround. Could you also please take a look at https://github.com/openwrt/openwrt/pull/4068? This is similar to a fix you previously made for sunxi, and also needed for 21.02. Thanks.