GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
chuck48 has joined #openwrt-devel
Ryncewynd has joined #openwrt-devel
gch981213 has joined #openwrt-devel
<oliv3r[m]>
hauke: next oddity I discoved, when I use generic mips kernel, and LZMA compression in the target Makefiles, no boot/output. but only changing it to (libdeflate-)gzip, it's fine. I'll try a few other compression algs but this is beyond weird ...
goliath has joined #openwrt-devel
cbeznea has joined #openwrt-devel
robimarko has joined #openwrt-devel
<stintel>
f00b4r0: robimarko: m400/m500 is x86 fyi and so is m440
<f00b4r0>
ah!
<robimarko>
stintel: ah, not interesting then
<dwfreed>
I mean, interesting as in powerful
<f00b4r0>
robimarko: maybe the hardware from #10941 would be more appealing to you then ;-D
<dwfreed>
but not interesting as in a challenge to port
<robimarko>
Well, that looks more interesting
<f00b4r0>
wait until you see the price tag xD
<robimarko>
And then they say its never been on the market
<robimarko>
Ok, nope
<f00b4r0>
robimarko: that's a devboard version, but there are commercial devices
<stintel>
can order on mouser, 52wk lead time, almost 5k EUR :D
<f00b4r0>
^
<f00b4r0>
:}
<robimarko>
Almost affordable
<f00b4r0>
i wonder if that would be one of the most (if not *the* most) expensive devices OpenWrt supports, assuming that PR gets in ;)
<robimarko>
My SparX-5 reference would be close
<robimarko>
Only 4.4k USD
<f00b4r0>
cheap :D
<robimarko>
When you are not the one paying then its great
<f00b4r0>
hehe
borek has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<karlp>
aiyion: have you seen the "partname: Ignore root=PARTUUID" patch?
<stintel>
this is in my staging tree awaiting feedback from Daniel
<Znevna>
and then
* Znevna
hides
<Znevna>
robimarko: thought so
<Znevna>
would be nice to fix it tho :P
<Znevna>
warnings scare people
<robimarko>
Fun thing is that the upstream commit to make it optional is backported already
<Znevna>
but why does it complain?
<robimarko>
Still looking for it
<oliv3r[m]>
is there an 'environment'-ish variable available in Kconfig files to determine if we are on a 32 or 64bit system? (and le vs be as well?) so that I could do 'select SYS_SUPPORTS_64BIT_KERNEL if ARCH64'?
<oliv3r[m]>
We set ARCH:=mips in our top makefile, so there's that
<robimarko>
depends on CPU_SUPPORTS_64BIT_KERNEL && SYS_SUPPORTS_64BIT_KERNEL
<robimarko>
Arch has to declare this and then 64BIT will be available
<oliv3r[m]>
I'm testing still, so give me a few compiles :S (e.g. an hour or two :p
<robimarko>
Yes, you are on the right track
<oliv3r[m]>
what track is that? :p
<robimarko>
CPU_SUPPORTS_64BIT_KERNEL will get selected based of the MIPS release that you select
floof58 is now known as Guest959
<oliv3r[m]>
so while SYS_SUPPORTS_64BIT_KERNEL and SYS_SUPPORTS_BIG_ENDIAN are set, there is still some detection in place?
floof58 has joined #openwrt-devel
<robimarko>
Yes
Guest959 has quit [Ping timeout: 480 seconds]
<robimarko>
CPU needs to be 64 bit as well
<oliv3r[m]>
let me ask it differently, which CPU's is MIPS_GENERIC_KERNEL targeted? generic enough for nearly all MIPS cores?
<robimarko>
So you need SYS_HAS_CPU_MIPS64_R1 or other MIPS64 flavors set
<oliv3r[m]>
yeah but MIPS_GENERIC_KERNEL basically sets them all
<oliv3r[m]>
I'm contamplating how generic this board-agnostic generic mips kernel is
<oliv3r[m]>
generic if you have MIPS64_R6 :p
<oliv3r[m]>
anyway, let me run my tests first, and then I'll tell you if lzma + R6 is causing my crashes
<robimarko>
There has to be a way to set the exact CPU in KConfig as well
<oliv3r[m]>
well if you go towrds 1 kernel to rule them all; like arm is trying to do; it should be possible with mips too?
<oliv3r[m]>
just have a fat kernel that you can run anywhere (as long as you have a proper devicetree)
<oliv3r[m]>
hmm, removed R6 and still crashes :) so that's good i suppose
<aiyion>
karlp: yes, I've just not had enough freetime to build and test it yet. But it reads like Christian already brought up devices like ours.
<robimarko>
Znevna: I will test on linux-next
<robimarko>
Cause, I have a feeling that the generic OF part was backported but NVMEM code for 6.3 was not
<dhewg>
nbd: mt76 has USB_DEVICE(0x7392, 0xb711) in mt76x0/usb.c and mt76x2/usb.c too, is that intentionally?
<robimarko>
Znevna: Ok, so the stupid warning exists in next as well
<Znevna>
nice
<mrkiko>
For forum post https://forum.openwrt.org/t/tl-mr6400-v4-qmi-not-working/147888 - my answer would be that ModemManager is needed; even to me uqmi didn't work but MM did. Installing MM on a device with 8MB flash is not ideal admittedly, but so far that was what I did. the device works then.
<robimarko>
rmilecki: Like Miquel pointed out, basically that cell is gonna need to be counted as 0 by default
<stintel>
wigyori: can you ping me when you did your sifiveu rebase? I'd like to see this land before we branch for the next release. I can test on hifive unmatched and give you a tested-by
<rmilecki>
robimarko: it is...
<ldir>
Ansuel: thanks :-)
<rmilecki>
or - it should be ;)
<Ansuel>
ldir for context i'm checking alpine support and i notice these thing were missing but bsd system have specific fixup for these missing libs
<robimarko>
rmilecki: AFAIK its currently not
<rmilecki>
robimarko: let me rephrase that - it should be by looking at existing code but it may be broken
<robimarko>
rmilecki: ok, I get you now
<robimarko>
It was also supposed to be fully optional but that is not working as intented
<rmilecki>
correct
<oliv3r[m]>
hauke: So for me, when I enable SWAP_IO_SPACE https://elixir.bootlin.com/linux/latest/source/arch/mips/Kconfig#L157 in combination with LZMA, the board doesn't even show boot info. Without LZMA but gzip it boots, but stops also relatively quickly also actually (cpu time source setup something)
dangole has joined #openwrt-devel
<Namidairo>
my condolences to whomever has to review your 807x PR
<Ansuel>
the only concern is the qsdk makefile
<Ansuel>
but rest of the commit is clean
<Ansuel>
we polished it for month
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<robimarko>
SSDK and NSS-DP is pretty much as clean as it can be
<Namidairo>
is that pcie 1x1 on the ax9000 working
<robimarko>
Yeah
<robimarko>
Its just QCA9889
<Namidairo>
yeah it's just that I remember pcie wasn't coming up not too long ago
<robimarko>
That was a while ago
<robimarko>
Got that tracked down to trying to read/write DBI space
<robimarko>
Before PCIe PHY was powered on
<robimarko>
That has been upstreamed and even backported to all of the stable releases
<Ansuel>
6.1 is still not in LTS
<Namidairo>
won't all these inbox/toh wiki links break later
<robimarko>
No idea what are they waiting
<Ansuel>
greg is heving some fun with OEM complaining about rust being a breaking change for some reason...
<robimarko>
Namidairo: What do you mean?
<Namidairo>
don't the pages get moved out of inbox later
<robimarko>
Namidairo: sorry, but you are gonna have to draw a picture for me
<robimarko>
No idea what you mean
<Namidairo>
all those device pages linked in the commit messages for the devices
<robimarko>
Honestly, no experience with that
<robimarko>
But I put the install instructions in the commit directly
<f00b4r0>
robimarko: i'm anticipating one problem with nvmem cells layouts for mikrotik devices: for devices which have both old and new style LZOR packging (where you can have a single wlan_data or 2 wlan_data files): I don't think this can be expressed in a dt-compatible way
<robimarko>
f00b4r0: oh yeah
<f00b4r0>
so I'm afraid we're screwed ;P
<Namidairo>
a few of them have prerequisite steps for gaining access to terminals linking to wiki pages
<robimarko>
Namidairo: I know, but SSH jailbreaks change all of the time
<robimarko>
No way they can fit in the commit itself as well
<Namidairo>
I guess ask tmomas or whomever was keeping the wiki clean
<mrkiko>
robimarko: is serial still mandatory to install OpenWRt on the AX9000 ? Guess yes, but I'm not updated on the matter
<robimarko>
mrkiko: No
<robimarko>
You can install directly from stock FW after getting root without UART
<mrkiko>
robimarko: thanks
<mrkiko>
robimarko: was just curious about that device, even tough I guess I am better in waiting for wifi 7 directly ...
<robimarko>
mrkiko: QCA just volleyed the bare minimum clock/pinctrl for IPQ9574
<mrkiko>
robimarko: still looks interesting hardware to try
<robimarko>
But HW is unobtanium
<Namidairo>
i feel like you may be waiting a while, even though the mt7996 just got prelim EHT patches in mailing list
<mrkiko>
robimarko: don'tknow what unobtanium means, but doesn't look like a good thing :D
<Namidairo>
that and yeah you ain't getting the hardware right now unless you're sampling for a huge run
<robimarko>
mrkiko: nyou cant purchase it
<mrkiko>
robimarko: Namidairo: thanks
<robimarko>
Xiaomi and TP-Link have techincally released BE models, but you cant buy them
<mrkiko>
I'll wait. As you probably already know, having a device I can recover without serial is very valuable to me :D
<robimarko>
All of the Xiaomi devices have that
<robimarko>
They have baked-in TFTP recovery in the bootloader
<robimarko>
However, you can only flash stock FW as they are checking the signature
<mrkiko>
robimarko: the problem is signed images if I remember correctly... so the AX9000 might load a TFTP image but I need to use the signed OEM and jailbreak again from there
<Namidairo>
they're just horribly inconsistent about what filename you require
<robimarko>
Yeah
<Namidairo>
sometimes it's ip address in hex, sometimes it's model name
<robimarko>
Its easy to see what its requesting, but I hate that they want signed images
<mrkiko>
robimarko: infact, fully agree. Even because obtaining the file for a stock firmware who is jailbreakable isn't always as easy as one might think, and trial and error process is not a thing here ...
<Namidairo>
they're kind of dead-ended as well because they still don't have regulatory approval for 6ghz in their main market
<robimarko>
mrkiko: Its actually easy to get whatever version of FW you want
<mrkiko>
robimarko: happy to know that
<robimarko>
API links for every model have been figured out and they provide nice JSON with all of the versions along with direct links
minimal has joined #openwrt-devel
<Namidairo>
yeah they don't really clean up their cdn luckily
<mrkiko>
After all, once you have one such file stored in a safe place, you're good to go
<robimarko>
It is getting damn hard to exploit them with every new model though
<robimarko>
I only have them as they are cheap so quite popular
<Namidairo>
huh, that's a QCN6274 in their new product.
<mrkiko>
wigyori: hi!!!!!! Thanks again for all your help and kindness!!
<mrkiko>
wigyori: it took a while for me to map your nick to you :D
<Namidairo>
have to beat all those mt7988 devices somehow.
<wigyori>
mrkiko: hi - sure thing, no worries :)
<mrkiko>
robimarko: wow, looks very ninteresting. Still, wonder what's the perspective of supporting it will be if trend continues as is - I mean, QCA gives out very little info and code, or am I wrong?
<mrkiko>
wigyori: :)
<robimarko>
mrkiko: QCA gives 0 docs, but all of the code that touches GPLv2 is released
<mrkiko>
Namidairo: :)
<robimarko>
The pain points like always will be wired networking
<Namidairo>
they give out code, it's just of questionable quality and tested against magical non-public firmware blob
<robimarko>
Quality is your tipical vendor crap
<mrkiko>
robimarko: yes, after having looked at the work that Ansuel did on qca8k ... I think I understand little more. I was happy to see that happening...
<robimarko>
qca8k is easy
<robimarko>
Datasheet leaked ages ago
<robimarko>
But then, datasheet was wrong in number of places
<mrkiko>
robimarko: but even then the hardware behaviour wasn't consistent with docs if I understood correctly
<robimarko>
Yeah, the tag info about reading MIB-s via ethernet packets was completely wrong
<robimarko>
And plenty other things
<Namidairo>
you should see the dumpster fire in their bluetooth chipsets
<mrkiko>
If the GL-AP1300 dsa conversion is merged, all the IPQ401x devices I have should be DSA-compatible :D
<Namidairo>
they had to retract some features after the fact "oops we couldn't support that after all"
<robimarko>
Namidairo: I hope to live and see a vendor SDK that isnt dumpster fire
<robimarko>
But some things like SSDK deserved to be instantly burned
<Namidairo>
eww mediatek are shoving 11ax-only variants under the same model name
<robimarko>
You mean Filogic or?
<Namidairo>
just skimming through this mt7996 patch on linux-wireless
<robimarko>
Oh you mean using the MT7996 name for completely different features
<Namidairo>
call it something else lol
<Namidairo>
hehe do { //blah } while(0)
<robimarko>
Its gonna be interesting to see how long will it take to be able to get them
<Namidairo>
given the spec does not finalise until the end of next year and all sure
<nick[m]12>
mrkiko: so I can not test what mac adresses are correct. can you give me your chnages?
<mrkiko>
nick[m]12: I did not changes, just applied the PR and flashed the device with u-boot's help. All works well, the only strange thing is - lan and wan have the same mac addr
valku has joined #openwrt-devel
<mrkiko>
nick[m]12: and i'm pretty confident the led thing should be OK by now
<nick[m]12>
mrkiko: can you compare the mac addresses against the stock firmware?
<mrkiko>
nick[m]12: not easily...
<mrkiko>
nick[m]12: if I have the chance I might try against the pre-dsa openwrt version... and let you know
<nick[m]12>
mrkiko: that would be nice
<mrkiko>
nick[m]12: by "it doesn't work" you mean - it gives you the"resourcebusy" error?
<Znevna>
rmilecki: yes, I can try
cmonroe_ has quit [Ping timeout: 480 seconds]
<Znevna>
hope I got the patch right
<Znevna>
yeah i didn't
<Znevna>
attempt #2
chuck48 has quit [Remote host closed the connection]
<robimarko>
You are gonna need to manually fixup the patch
<f00b4r0>
I love it how homebrew thinks they know better than their users. "We won't add sshpass because it makes it too easy for novice SSH users to ruin SSH's security"
<f00b4r0>
do I regret using that garbage
<PaulFertser>
Gentoo prefix runs on macOS too.
<robimarko>
rmilecki: That patch fixes things
<robimarko>
Warning is gone
<f00b4r0>
PaulFertser: I normally rely on MacPorts, which is much saner in every aspect. Unfortunately that's not what I have on this machine (I installed homebrew at a time I didn't know better). Luckily sshpass isn't too hard to build by hand
goliath has quit [Quit: SIGSEGV]
cmonroe has joined #openwrt-devel
<Ansuel>
jow wonder if you can give some feedback about the luci pr and after i merge all the iwinfo and rpcd fixup wonder if you can delete the additional extra branch (those repo have policy to reject force push and delete so I had to create a new branch)
<mrkiko>
f00b4r0: naive question regarding MAC OS - what if you break the system somehow or you simply have too many things around installed iva 2make install" and so on, so that no package manager knows about them... is there an easy way to "clean" the OS without re-configuring / re-installing everything?
<f00b4r0>
mrkiko: there are several options depending on how "clean" you want the system to be
<f00b4r0>
you could rm -rf /usr/local and start over, to boot. That's quick and dirty, but it works
<mrkiko>
f00b4r0: so all changes are in that dir?
<f00b4r0>
it's common for handbuilt software to install in /usr/local by default
<PaulFertser>
And that's not macOS specific.
<mrkiko>
f00b4r0: ok; next "more clean" ?
<f00b4r0>
mrkiko: i think that's quite off topic, but you could spawn a new APFS container, install a clean system there and then "migrate" your old data via the migration assistant.
<f00b4r0>
then you delete the old volume.
<f00b4r0>
this would give you a much cleaner system, since you would essentially have a fresh install + whatever you chose to move over
<mrkiko>
f00b4r0: thanks
<f00b4r0>
np yw
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
<Ansuel>
btw mkimage can compile correctly on alpine with musl but doesn't on macos in 22.03
<Ansuel>
what a meme -.-
<f00b4r0>
heh
<stintel>
meh power outage for 40 minutes already
<Znevna>
funky
<Ansuel>
any idea of the reason? storm?
<stintel>
no idea
<stintel>
it's just the local area (few streets)
<stintel>
it happens regularly but not for this long
<Znevna>
windows 10 is weird
<Ansuel>
?
<Znevna>
if you try to add a network using wps which is broken in openwrt
<Znevna>
and you get the wrong password prompt, and you enter the right password, it still tries to use a wrong password to connect
<Znevna>
x.x
<Ansuel>
wps works only one time
<Ansuel>
next connection will result in mismatched psk
<Ansuel>
no time to bisect
<Znevna>
I think it works when using only wpa2?
<Znevna>
didn't try
<Znevna>
I don't use it anyway :P
<Ansuel>
had lots of time with a printer that loved using wps but didn't work after one day....
<Ansuel>
took month to discover
<Znevna>
I was trying to get my sniffing laptop online and I remembered I've played with WPS the last time
<Habbie>
catching up on #openwrt-devel, i see
<Habbie>
An application linking
<Habbie>
statically against it has to follow the LGPL, when an application links
<Habbie>
dynamically against it there is not need to follow LGPL.
<Znevna>
rmilecki: I know you're busy, what data can I gather for the trx firmware? I have a working asuswrt based build system (swrt, I didn't bother getting the official GPL to running state) that produces proper firmwares
<oliv3r[m]>
anybody know anything about SWAP_IO_SPACE https://elixir.bootlin.com/linux/v6.1.4/source/arch/mips/Kconfig#L157 ? With that option set, I can't boot LZMA compressed kernels, nor can I boot anything beyond the first 10 lines of printk's. Why is it 'so generic' and why is it not working on our realtek platform?
<robimarko>
* Sane hardware offers swapping of PCI/ISA I/O space accesses in hardware;
<robimarko>
* less sane hardware forces software to fiddle with this...
<karlp>
yet again, someone other than snps doign all their work for them I see?
<robimarko>
I have sent a patch to make it source-only as target seems completely unused, download statistics are showing the same
shibboleth has quit [Quit: shibboleth]
<nick[m]12>
robimarko: what about making ath25 source-only?
<Ansuel>
i just realized i may have for real converted each clk driver for ipq806x to parent_data o.O
<robimarko>
nick[m]12: No idea how popular ath25 is
<f00b4r0>
i suspect "not very much" ;P
<robimarko>
Well, it is one of those that is left to the end to convert to new kernel
<dangole>
nbd: i'm observing performance degradation on mt7986 with gmac1 connected to 1G sgmii PHY. before your multiqueue patch RX and TX would both be around 930MBit/s. after multiqueue patch TX only gets up to around 670MBit/s.
<robimarko>
Oh, so it was dropped in 2020 and resurected couple of days later
<dangole>
nbd: commenting out the SPEED_1000 case in the patch fixes it, so I assume the values picked there are wrong
<f00b4r0>
robimarko: i remember something like that yes. It's one of those that don't want to die ;P
borek has quit [Ping timeout: 480 seconds]
<f00b4r0>
robimarko: then again, moving to source-only is much less abrupt than outright drop
<robimarko>
f00b4r0: It did have a whopping 4 downloads of the generic image
<f00b4r0>
lol
<f00b4r0>
yeah i vote for moving to source-only as well
<robimarko>
It is it the 10 days of january, but still
<f00b4r0>
with a bit of luck nobody will notice
<robimarko>
I assume most users are downstream anyway
<dangole>
robimarko, f00b4r0: you'd be surprised how many ar2xxx WiSoC systems are still in use (esp. older ubnt outdoor gear, like ubnt bullet)... i know at least one place still using a bunch of them, slowly replacing them with newer ubnt outdoor gear when ever one of them dies.
<robimarko>
I am not surprised, but those arent the people that update the SW
<dangole>
robimarko: in this case they are even using batman-adv mesh, and yes, they are updating with every stable openwrt release (but building from source)
<f00b4r0>
dangole: do they have enough storage/ram to run anything recent?
<robimarko>
If they are building downstream then making it source-only wont hurt anybody
<dangole>
f00b4r0: some are 8M/32M, so not soooo bad. it's more then 120~180MHz MIPS4Kc which makes you fall asleep while trying to do anything with them...
<dangole>
robimarko: yes, source-only won't hurt.
<f00b4r0>
*nod*. Besides 32M is no longer "supported"
<robimarko>
BTW, can you poke those people to migrate the target to 5.15
<dangole>
robimarko: i'm afraid it's going to be them poking me to do that, and they will do testing and report back....
<f00b4r0>
heh
<robimarko>
dangole: as long as somebody does it, cause its a straggler again
<dangole>
robimarko: ouf... one iteration of testing is like 30 minutes on those. flashing takes like 10 minutes, first boot after upgrade another 10 minutes, ...
<f00b4r0>
ugh
<robimarko>
That sounds like a world of pain
<f00b4r0>
have to wonder what's the point really
<robimarko>
Like watching paint dry
<f00b4r0>
lol
<nick[m]12>
I already did the 5.15 migration
<nick[m]12>
Already poked someone to test. However, I thought that they only have 4 MB flash.
<nick[m]12>
If some targets have also 8 MB, I think we can still keep it. ;)
<nick[m]12>
Proabaly used by some radio amateurs. I would test 5.15 myself, however, I don't own any device. :/
<robimarko>
Nobody is talking about dropping it, just not building it anymore on buildbots
<f00b4r0>
Ansuel: btw you still have #11751 open but if I'm not mistaken you've merged that
<Mangix>
Add the packages feed and alpine failures increase
<Ansuel>
Mangix why you want me to suffer ahahah
<Ansuel>
f00b4r0 will autoclose when a commit will be merged
<Mangix>
most notably perl fails
<f00b4r0>
Ansuel: it didn't. It shows conflict now.
<Mangix>
The one in packages is old
<Ansuel>
f00b4r0 trust me it will not the first time this happen. looks to be a problem with how the github fork is synced with the real git repo
<f00b4r0>
Ansuel: I trust you. I just wanted to raise your awareness ;)
<Ansuel>
but it's probably a bug in github
<f00b4r0>
Ansuel: i get that, but that PR won't close itself unless you do it, hence me pinging. Unless we don't care about stale PRs that are already merged that is :)
<Ansuel>
it will close itself
bluew has joined #openwrt-devel
<rmilecki>
thank you robimarko for testing
<f00b4r0>
oh dear. 1.7k GH issues. This is getting out of hand :P
<Ansuel>
we still have to close the one related to deprecated openwrt version
<f00b4r0>
#11650 rings a bell. I think I saw something similar on mt7621
<Ansuel>
hauke btw i think i will just use an action to get changed files and based on that select what to build for the kernel test
<Ansuel>
it's an alternative for your pr with the script
robimarko has quit [Quit: Leaving]
<slh>
what are the odds that those who did break their ax3600 during the migration might have used a qsdk based build with changed smem and everything in the past? I mean there are too many reports for mere finger trouble, but not enough to see a pattern
<slh>
(although I wouldn't disregard finger trouble either)
Ansuel has quit [Read error: Connection reset by peer]
<Ansuel>
robimarko i'm testing a fixup for the toolchain problem
<hauke>
Ansuel: thanks
<aiyion>
stintel: Caught it by chance; I'm not sure whether it worked in 5.10, but it looks like in 5.15 the NanoPi R1 does not show a wifi interface and fails to scan for near networks.
<aiyion>
Sorry I didn't see it earlier. Yesterdays screenlog does not show it either.