<Borromini>
robimarko: can I pick your brain on the QCA8081 support for 5.15/RB5009UG? After e1242fc, that backport breaks. If I'm not mistaken, the QCA8081 backport patches are for 5.16 and thus should get applied first (e1242fc being 5.18 patches).
dgcampea has quit [Remote host closed the connection]
dgcampea has joined #openwrt-devel
<Ansuel>
rmilecki still have to push offload and generilize LEDs handling for dsa switch
<rmilecki>
well, there is always sth more to add ;)
<rmilecki>
still I think it took years to get those changes accepted, didn't it?
<robimarko>
Well, Ansuel was the only one to make a proper effort
<robimarko>
Everybody else pretty much gave up after initial comments
<robimarko>
But, this is one of those that everybody needs but its impossible to satisfy all of the comments
<Ansuel>
noticing more and more how people are really not used to the art of compromise
<robimarko>
Well, that takes time and patience, also dealing with crazy requirments
<Ansuel>
rmilecki the hard part is give enough proof that the implementation is generic enough... and actually the next series will be the really hard part
<Ansuel>
but decided a series of 11 patch was already big enough for submission
<robimarko>
Yeah
valku has joined #openwrt-devel
<robimarko>
BTW, what are we going to do regarding the Compex PR without a BDF so WLAN doesnt work?
<Ansuel>
will have to take a decision but i will give it some days to boil
<Ansuel>
ahahah
<Ansuel>
maybe the BDF will magically appear who knows
tidalf_ has joined #openwrt-devel
<Ansuel>
using the default stuff is for sure a no go... there is not a single chance compex used a 1:1 reference design
<Ansuel>
btw robimarko discovered why i got no update... some apt update destroied the apt.conf so been weeks that i don't have pkg update...
<Borromini>
robimarko: i'm going through git blame still but at first glance the modifications I did do seem correct, but I have no serial on the RB5009UG =)
tidalf has quit [Ping timeout: 480 seconds]
tidalf has joined #openwrt-devel
<robimarko>
Ansuel: Well, we can always just push the BDF from the stock FW
<Ansuel>
yep
<robimarko>
Borromini: RB5009 needs some love
<Ansuel>
think we will follow that path
<Borromini>
robimarko: true enough but you got your plate full I reckon.
<robimarko>
Borromini: Kind of, but I am on vacation whole next week
<robimarko>
Biggest issue is how to pass a DTB
<Borromini>
ok :)
<Borromini>
i saw your forum post, yes
tidalf_ has quit [Ping timeout: 480 seconds]
<robimarko>
Ansuel: Well, trying to use make 4.4.1 did not help
<Ansuel>
did you tried with more verbose option ?
<Ansuel>
i assume make gives very """"""useful"""""" info on what is broken
<robimarko>
There is a even more verbose mode?
<Ansuel>
--trace ?
<Ansuel>
i feel like ubuntu just dropped any devel apt source...
<robimarko>
Well, that only prints more info during the setup
<Ansuel>
line 852 wonder if that sed is problematic
<Ansuel>
api_access.d.tmp is correctly created right ?
torv has quit [Remote host closed the connection]
<robimarko>
Well, the error seems to be random
<robimarko>
The file I mean
<robimarko>
For example, now its failling on *** No rule to make target '/home/robimarko/Building/AX3600/ipq807x-5.15/build_dir/target-aarch64_cortex-a53_musl/linux-ipq807x_generic/qca-ssdk-2022-09-12-628b22bc/build/linux/KSLIB/adpt.d', needed by 'adpt.o'. Stop.
<Ansuel>
so a new run result in the error in another place?
<robimarko>
However, adapt.d exists
<Ansuel>
you are running with -j1 ?
<robimarko>
Yeah, its not parallel
<robimarko>
SSDK is prevented from building in parallel anyway
<robimarko>
As it falls apart otherwise
<Ansuel>
i'm considering to add make as an host tool instead of fixing my broken apt ....
<robimarko>
Ansuel: Its extremely easy to compile make
<robimarko>
You dont even have to install it in PATH
torv has joined #openwrt-devel
<Ansuel>
can't be a regression with makefile right?
<robimarko>
My guess is that it worked by luck so far
<robimarko>
And then make got something fixed up and now we are SOL
<robimarko>
Cause, we both know that SSDK make structure is crap
<robimarko>
make[4]: *** No rule to make target '/home/robimarko/Building/AX3600/ipq807x-5.15/build_dir/target-aarch64_cortex-a53_musl/linux-ipq807x_generic/qca-ssdk-2022-09-12-628b22bc/build/linux/KSLIB/adpt.d', needed by 'adpt.o'. Stop.
<f00b4r0>
hmm, I'm seeing ramoverlay activated on my 22.03 setup. /me scratches head
goliath has joined #openwrt-devel
<f00b4r0>
user.notice kernel: [ 8.562591] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
<f00b4r0>
hmm
<Ansuel>
mhhhhhh
<Ansuel>
is it hmmm or mhhhh ?
<f00b4r0>
depends on profound the mmhming is to be ;P
<f00b4r0>
interesting. After reboot the extraneous overlay is gone
<f00b4r0>
although prior, logread shows successively "synchronizing overlay" and "failed to sync jffs2 overlay". Which kinda look scary.
<f00b4r0>
seems like an old problem judging by a quick google search. I guess I never paid enough attention
<Ansuel>
robimarko starting to consider we have to report this to make
<Znevna>
weird, can't seem to reproduce the missing wireless interfaces issues on this Archer C6U device
<f00b4r0>
err... is iptables-zz-legacy supposed to work alongside nftables? I somehow ended up with the former installed on 22.03 and I see a different set of rules in iptables -L vs nft list ruleset
* f00b4r0
is very confused
<Znevna>
heh
<Znevna>
22.03.4 broke it
<Znevna>
so something in master fixed it
<Znevna>
interesting
<robimarko>
Ansuel: I kind of doubt that its make-s fault
MaxSoniX has quit [Quit: Konversation terminated!]
<Ansuel>
robimarko that reverse thing is suspect
<Znevna>
do_page_fault(): sending SIGSEGV to ujail for invalid read access from 00000036
<f00b4r0>
so init.d/foo reload bypasses disabled state. That's a bummer.
tidalf_ has quit [Ping timeout: 480 seconds]
<f00b4r0>
jow: is this by design?
<Ansuel>
restar ttoo ?
<Ansuel>
also start doesn't run if it's disabled?
<f00b4r0>
restart and start would start even if disabled, but that seems "expected".
<Ansuel>
reload call restart if reload is not defined
<f00b4r0>
ah
<Ansuel>
so that should also be expected?
<f00b4r0>
then this explains that
<olmari>
and disabled usually means "don't start automatically at boot", in case you wanted to know ;D
<Ansuel>
robimarko btw makefile structure of ssdk is real trash
<Ansuel>
like REAL
<f00b4r0>
yes. Which is exactly the point, except that in the case of uhttpd, uci-defaults/00_uhttpd_ubus (run at first boot) will unconditionally (re)start uhttpd
<Ansuel>
well the uci default script should be fixed
<Ansuel>
and return early if uhttpd is disabled
<philipp64>
anyone know what determines what interfaces the system sees on startup? for some reason, on my VM, it's only detecting 1 of the 2 configured Ethernet interfaces... can't figure out why.
<f00b4r0>
Ansuel: imho I think the "reload" procd routine should really be the place to fix: it should be a NOP if the service isn't running.
<f00b4r0>
this way it would solve all such cases
<f00b4r0>
but maybe there's a good reason not to do that
<Ansuel>
eh it's difficult
<f00b4r0>
why? procd has all the status data on processes after all? :)
tidalf has joined #openwrt-devel
<Ansuel>
uci defaults may touch other kind of thing so it's not very defined
<Ansuel>
what should be skipped
<f00b4r0>
that's exactly why I don't want to touch this
<f00b4r0>
but when a defaults script calls reload to update a (presumably running) configuration, this shouldn't start a non-running process
<f00b4r0>
hence my reasoning that "reload" is the place to fix. Off hand I can't think of a reason why reload would equate "restart"
tidalf_ has joined #openwrt-devel
cbeznea1 has quit [Quit: Leaving.]
<rmilecki>
hauke: do you have any plans/time to work on lantiq and 5.15?
tidalf__ has joined #openwrt-devel
tidalf has quit [Ping timeout: 480 seconds]
tidalf_ has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
Ed has joined #openwrt-devel
minimal has joined #openwrt-devel
Ed has quit [Remote host closed the connection]
tidalf has joined #openwrt-devel
tidalf_ has joined #openwrt-devel
tidalf__ has quit [Ping timeout: 480 seconds]
tidalf has quit [Ping timeout: 480 seconds]
<Ansuel>
f00b4r0 i wonder if a good idea might be add an helper to make it easier to add this check in uci defaults? still think this problem can be only fixed in the uci-defaults scripts as someone can totally do a start or a restart
<Ansuel>
we are assuming everyone use reload in those script
<f00b4r0>
i don't understand. Are you saying it's okay for "reload" to re/start/ a non-running service?
<Ansuel>
i'm saying that the thing should not be called in the first place. Another script might call restart and we would have the same exact problem
<f00b4r0>
calling restart would be a bug. calling reload to reload a running configuration seems legit
<Ansuel>
can you check the usage of reload in the openwrt repo and feed?
<Ansuel>
i'm curious
<Ansuel>
should be a simple regex ?
<Ansuel>
/etc/init\.d/.* reload
<Ansuel>
for master i can see only uhttpd that suffer from this
<Ansuel>
looking at the usage, it may not be a bad idea but i would wait for jow feedback if he wants to give us some ideas
<Ansuel>
btw the restart fallback is there to handle app that doesn't support a "light reload" and require the thing to be stopped and started again to apply the new config
<Ansuel>
but i agree that doesn't make sense to reload something that wasn't running in the first place
<f00b4r0>
Ansuel: the fallback is a convenience workaround that breaks most expectations from init systems (sysvinit or systemd)
<f00b4r0>
reload should return an error if not implemented, not fallback to restart by default.
<f00b4r0>
(imo)
<barhom>
I remember reading about how dnsmasq decides on which DNS resolver to use. It starts with sending to all configured and then picks the one that's the fastest. Anyone remember where that information can be found? (Was it a RFC?)
<f00b4r0>
systemd will return an error when issueing a "reload" for an inactive service, and likewise most sysvinit scripts that implement "reload" will also perform that check. So imho the current fallback is a bug in procd.
spb has joined #openwrt-devel
spb has quit []
spb2023 has joined #openwrt-devel
<robimarko>
Ansuel: Yeah, SSDK makefile structure is so crazy and its so flimsy
<robimarko>
My goal is to eventually get rid of it as its just causing pain
<Ansuel>
our goal is to get rid of the entire ssdk but too much effort currently
<robimarko>
Yes, I would like to completely remove SSDK
<Ansuel>
still no clue of why the thing doesn't work with 4.4
<robimarko>
Same, the thing that is weird to me is that its complaining that the file is missing but its there
<robimarko>
And then you rerun compilation, it finds the file and then next one errors out
<Ansuel>
My idea is that someone is deleting the previous file
<Ansuel>
Or dep are not correctly detected
<robimarko>
They are not being deleted
<robimarko>
Its looking like a race issue
<Ansuel>
And new make just changed the logic in that
<spb2023>
I'm looking for a basic guide/example on how to create a package a python app to an ipk. I've followed the 'c'-based helloworld.c example and have no problems with that. But when I try to create a 'helloworld' python equivalent the IPK create fails. Does anyone have any pointers/examples on how to form the Makefile correctly and how to build the ipk?
<robimarko>
But, how can you have race condition with a single thread building?
<Ansuel>
I bet it's caused by compiling everything in a directory and doing some magic with referencing dep
<oliv3r[m]>
o/
<f00b4r0>
robimarko: i have no idea what the situation is but yes it can happen
<f00b4r0>
e.g. if background jobs are starte
<f00b4r0>
d
Borromini has quit [Ping timeout: 480 seconds]
<Ansuel>
oliv3r wants to have fun with some makefile?
goliath has quit [Quit: SIGSEGV]
Borromini has joined #openwrt-devel
gch9812137 has joined #openwrt-devel
gch981213 has quit [Read error: No route to host]
gch9812137 is now known as gch981213
<oliv3r[m]>
i dislike makefiles :D
<Ansuel>
we convert ssdk to cmake ?
<Ansuel>
:D
<oliv3r[m]>
i have fought with the openwrt build system too many time
<oliv3r[m]>
meson :p
<f00b4r0>
meson? Isn't that that build system that always requires the most recent python version and isn't backward compatible? :3
* f00b4r0
hides
gch981213 has quit [Ping timeout: 480 seconds]
<oliv3r[m]>
probably; but overal, it ain't bad :)
<f00b4r0>
famous last words xD
<Ansuel>
exploding meson build in the background
<robimarko>
f00b4r0: Well, SSDK is kind of weird, I have a feeling it runs multiple make jobs
<f00b4r0>
robimarko: that wouldn't surprise me
<robimarko>
And that would be the cause of breakage probably
cbeznea has joined #openwrt-devel
<f00b4r0>
*nod*
<robimarko>
I had it break in same fashion on 4.3 couple of times, but it was so rare that I couldnt bother to try and fix it
<Ansuel>
so makefile is ignoring -j1 ?
<oliv3r[m]>
Ansuel: what can I do to start moving some MR's along again? (like the led one for example)
* f00b4r0
bbl - dinner time
<oliv3r[m]>
I've just got a nother vendor sending me hardware :)
<robimarko>
Looks like it cause, look at the make[n] in the log
<olmari>
Ansuel: Also possibility that it "jsut" runs multiple make's itself, no matter each of them alone runs with -j1 (just theory)
<robimarko>
oliv3r[m]: You are really intent on making those RTL switches actually run
<robimarko>
olmari: To me it looks like thats the case
<Ansuel>
well yes they are multiple run of make
<oliv3r[m]>
robimarko: very much so! It would be the first multiport switch in openwrt :D
<oliv3r[m]>
well not 'would' because we have some already there :p
<oliv3r[m]>
but I really want to see this stuff in mainline; and that verizon modem looks super interesting (not for me here in the EU) but huge potential user area
<Ansuel>
oliv3r IMHO we should detach the realtek source from openwrt source...
<oliv3r[m]>
so forking it?
<Ansuel>
that was things can be developed in mismatched times
<oliv3r[m]>
I thought of that too; just dump it :p it's soooo bad right now
<Ansuel>
(openwrt targetting a version on this external realtek driver)
<oliv3r[m]>
well the problem imo is that it WAS merged , it IS in there
<Ansuel>
also another problem is that i think the driver is shipped with src way? aka adding files to the kernel right?
<oliv3r[m]>
so either drop it; or work on it; but working on it is made particular hard
<Ansuel>
so it can't be build as an external repo with a dedicated makefile and package
<Ansuel>
from what i can see the main problem is that you need to submit patch to openwrt... then need to be reviewed and accepted since they will be included in master image directly
<oliv3r[m]>
the SDK is horrible, birger and marcus took months/years of work to migrate the fugly SDK, into what we have within openwrt now, which is horrible code (copy/paste etc) BUT it's all (self-contained with)in openwrt
<Ansuel>
yep and the fact that is self-contained it's the ONLY reason that thing could be accepted
<Ansuel>
realtek is currently not selfcontained so the quality of the changes MUST be high
<oliv3r[m]>
well technically, all functionality is there, in openwrt; its just its broken, ugly etc. it needs to be cleaned up and fixed! once that is in place; it makes upstreaming much easier
<oliv3r[m]>
so there's no external realtek dependency, that's already fixed
<oliv3r[m]>
but there's so many assumptions, hardcoded stuff, just ugly hacks
<Ansuel>
oliv3r would it take you lots of time to move it to a self contained driver?
<oliv3r[m]>
well the biggest problem is fixing things and understanding things; that's the MR's i'm offering, getting the current code base in a understandable and clean state; from there (which I am already doing) moving to upstream
<oliv3r[m]>
but unlke sander, I don't want to rush upstream as the whole grail. It's the ultimate goal, but I'd rather take it slow
<Ansuel>
and these thing can be made much quicker if code is in his own repo detached from openwrt master repo
<oliv3r[m]>
but look at the led patches I sent in; it assumed that you had a xgs1250, and leds where hardcoded (via the dts in hex) to setup the leds. I made it a little more dynamic, added defines for the magic values etc. but the led init function is still part of ethernet_init :p
<oliv3r[m]>
well it IS detached right now, i have it in my own branch/fork
<Ansuel>
link ?
<oliv3r[m]>
but now things live in two places; in master, and in my branch
<Ansuel>
that way probably you can understand me better what I mean
<oliv3r[m]>
afaik i'm the only dev left for the realtek target :p
<Ansuel>
oliv3r yep i have to check with svanheule... well things will be the same just more organized and focused stuff... i can assure you qcom user don't care about realtek driver devlopment
<oliv3r[m]>
excelt for the verizon stuff :) where they bundle qcom hardware, with the rtl9301 switch chip :)
<Ansuel>
oliv3r in master it's at 4th page
<Ansuel>
on a dedicated page it would be right on the first one
<Ansuel>
or also you can spam pr with more focussed feature/fix
<oliv3r[m]>
heh, there's just one issue; I also have a dozen or so generic openwrt shell script fixes; where the first comment would be 'point me to the user'
<Ansuel>
(but only for the ethernet PHY and dsa driver)
<Ansuel>
rest of the stuff can stay in realtek target
spb2023 has quit [Quit: Page closed]
<Ansuel>
i assume those doesn't change that much
<oliv3r[m]>
right, but; the bottleneck again would be manpower; having things better organized; I'm in favor of ofcourse; though Ir eally prefer to develop in an actual kernel tree :) (which I'm doing currently)
<oliv3r[m]>
they need to be completly rewritten
<oliv3r[m]>
I just haven't looked at that stuff for the most part
<oliv3r[m]>
and the other stuff there is 'new' that I wrote
<oliv3r[m]>
so it would all be changing
<Ansuel>
well first thing to check is if they can be build as modules
<Ansuel>
if that is doable than it's just a matter of creating makefile
<oliv3r[m]>
what's the development-flow for a setup like that?
<Ansuel>
compiling an external module it's the same exact thing of compiling one like it was in the kernel
<oliv3r[m]>
as I'm developing, sometimes from scratch, and want to iterate afap obviously
<oliv3r[m]>
well from an openwrt toolchain pov i mean
<oliv3r[m]>
handling openwrt is already tiresome as it is (it really is not intended to develop with :(
<Ansuel>
from your develop way if the makefile is not trash (like it is with ssdk)
<Ansuel>
editing stuff in build_dir would result in having the external module built
<Ansuel>
you don't have to recompile the kernel, just one time
<oliv3r[m]>
that could be faster indeed :)
<oliv3r[m]>
though the downside of the build_dir is, it's not a git repo; so i loose git tracking, commitability etc
goliath has joined #openwrt-devel
<Ansuel>
yep that is the only problem but i assume you have to test lots of stuff before commiting
<oliv3r[m]>
anyway, you talk this over with svanheule and see if you can move things forward; I just fear that development effort will be higher; MR's will sit there still for 6 month; though I can poke you then to 'look at this repo with tons of MR's :p
<oliv3r[m]>
well the 'diff-view' is nice :) 'added lines' (i have a VI plugin for that)
<Ansuel>
well see in this way... for a reviewer it's better to see 20 pr well organized than one pr with 200 commit to review :D
<oliv3r[m]>
250 commits :p
<oliv3r[m]>
though I am only offering them in tiny chunks, exactly because of that :p
<Ansuel>
also i can assure you having a self contained git project is much better than the entire openwrt repo
<oliv3r[m]>
but you go and see if you guys can re-organize yourself to hopefully improve the situation :)
<oliv3r[m]>
yeah, I'm happy using 'external kernel tree' but getting it updated is a pain
<oliv3r[m]>
as I have to use my sccript to generate a new tree
<oliv3r[m]>
but we do still have users that actually want to test/use the changes asap :p
<Znevna>
it's nice that realtek supports your work
<oliv3r[m]>
but you still must understand my frurstration. I've been working on the realtek target for more then 6 months, with the understanding 'oh i just have to add a devicetree entry for my switch', with 'but i need led support sorted so the leds work right' and 7 months later; we're still never
<Ansuel>
user will be able to test the changes by simply bumping the package
<oliv3r[m]>
Znevna: freudian slip? I guess you meant to say "its nice that you work supports realtek' cause realtek doesn't know/care that I'm doing this? :)
<Ansuel>
oliv3r i had a similar problem with LEDs so i know the feeling
<Ansuel>
and also with qcom stuff
<oliv3r[m]>
never -> nowhere
<olmari>
or.. sarcasm ;)
<oliv3r[m]>
Sami Olmari: there was no /s :p
<Znevna>
I'm not familiar with /s
<Ansuel>
what i lerned is that the the little the patch the better... if you send a series of more than 15 patch 99% reviewers will skip
<Ansuel>
if they are not intrested
<Znevna>
but maybe they should
<oliv3r[m]>
yeah, i split the led one in 8 commits; i can split it into even less :p
<oliv3r[m]>
and have even more smaller MR's :p
<oliv3r[m]>
but there's also some unwillingness to get stuff in; if it's not gold-plated perfect
<oliv3r[m]>
which I get; but I also say 'if it makes things better, just merge it'
Borromini has joined #openwrt-devel
<oliv3r[m]>
i mean; if I'd made things worse; sure, flame me; it is so; but I'm just trying to improve things, in small slow steps :)
<Ansuel>
again the main problem is that changes will go directly in openwrt master and they will sustain higher code quality
<oliv3r[m]>
sure, but if currently in master is a piling steaming turd; and we improve it slowly; to make it less steaming of a turd; how is that bad?
<oliv3r[m]>
the code quality of what is now in master is really horrible (for the realtek target)
<Ansuel>
i should really ask sven
<oliv3r[m]>
roflmao, sander; but I also do the same thing in my head :)
<oliv3r[m]>
Sander van Heule -> sven :)
<Ansuel>
sand looks wrong
<oliv3r[m]>
I think this predates sander; i think j. chripin 'just merged things'
<oliv3r[m]>
j.crispin :p
<oliv3r[m]>
but talk to sander :) though I think he's awol
<Ansuel>
i will just send an email to both
<oliv3r[m]>
me and sander?
<oliv3r[m]>
fine by me :)
<oliv3r[m]>
does it make sense that the SFP code tries to read a non-existing eeprom during boot? I suppose it could be useful if there's no LOS or Presense GPIO's
<Ansuel>
mail sent
<Ansuel>
anyway again i would test if it can be built as external module
<oliv3r[m]>
the build system can include the module in the initramfs right?
<Ansuel>
yes
<Ansuel>
wiki have that documented
<oliv3r[m]>
good; i'll leave the infra work to sander though :) i'd rather spend my energy on actually supporting this stuff :) i want to start using my switch! :p
Tapper has quit [Read error: Connection reset by peer]
madwoota has quit [Ping timeout: 480 seconds]
<hauke>
rmilecki: aparcar[m]: Ansuel: I plan to look into the lantiq DSA problems. xdarklight already has some linux patches in his tree and there was a longer discussiuon upstream
<hauke>
I can not promise when I find some time for it
<Ansuel>
if you can, can you give some link to the patch or to the discussion? I'm curious of the actual problem
danitool_ has joined #openwrt-devel
<Ansuel>
anyway if we manage to fix them in the RC stage then lantiq is saved from dropping