<Ansuel>
We can't really wait for all their series to be applied for a simple feature... Need to think of a good way to answer to that :/ For sure not following why they are not ok with that
<robimarko>
Who the hell cares if they are ok or not
<Ansuel>
robimarko i would love to collaborate and starting a fight isn't really in my plans... for sure it's only beneficialif that single feature was handled separetely looking at the state of the ipq50xx series they linked...
<robimarko>
Ansuel: Well, you cannot collaborate with them, look at the whole ipq50xx series
<robimarko>
You can just wait for Andrew or somebody else to chime in pointing out it makes no sense to wait for the whole series
vincejv has joined #openwrt-devel
<Ansuel>
yep I will totally send v2 I will just give them reason of me ignoring the "gentle reminder"
slh64 has joined #openwrt-devel
<Ansuel>
and now have to wait 12h to send v2...
robimarko has quit [Ping timeout: 480 seconds]
robimarko has joined #openwrt-devel
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
Daanct12 has quit [Quit: WeeChat 4.1.2]
<rmilecki>
robimarko: Ansuel: what QCA patches is that about?
mcbridematt has quit [Read error: Connection reset by peer]
<jeff___m>
I finally got ath12k working with support for both bands, iw list looks fine (https://pastebin.com/vffQH6RN), however Luci shows the 2.4GHz interface as "Generic Mac80211AX.." and does not let me choose which channel to use in AX mode, and on the 5GHz interface it only lets me choose the channel, but not the wireless mode to start the AP in. Where do I start to resolve the issues in Luci reco
<jeff___m>
gnizing the capabilities?
<robimarko>
Ansuel: And Andrew stepped in as expected
<jeff___m>
robimarko: any clue why luci might be showing weird capabilities? I think the drivers are now working successfully, as far as I can tell iw is showing HE/80211AX capability..
<robimarko>
jeff__m: No idea, but the generic name means nothing
<robimarko>
Everything that doesnt have an entry in iwinfo is just called generic
<jeff___m>
Gotchya. So to fix that I would need to add an entry to iwinfo
<robimarko>
Yes, I guess you have an PCIe card?
<jeff___m>
Correct its a QCN9274 mpcie card
<jeff___m>
So the luci selection page is probably a configuration issue or something? Or is there any reason it will remove UI elements like choosing the mode
<robimarko>
But if mode is missing that iwinfo probably cant identify it
<jeff___m>
I also wonder, though 2.4 is shown as Generic 80211AX.. why might 5GHz be shown as Generic unknown. Maybe thats a clue
<jeff___m>
Oh ok. Ill try and add that and see if it fixes issues downstream
<jeff___m>
Classic. The luci problems were a wireless config issue. I removed /etc/config/wireless, ran "wifi config", did /etc/init.d/network restart and the issues are now gone.
philipp64 has quit [Quit: philipp64]
f00b4r0 has joined #openwrt-devel
<Ansuel>
Well situation is getting worse for my poor MDIO patch... I smell downstream patch needed...
jeff___m has quit [Remote host closed the connection]
<enyc>
ooi (not that i have any particular need for) , any inklings when 23.05.3 might be on the horizon? is just not so much stuff needing to change at the moment?
<robimarko>
Ansuel: Its time for a downstream patch
<robimarko>
Upstream politics will take time
<Ansuel>
it was suggested to wait till monday
<robimarko>
Monday is rather far
<robimarko>
Its easy to drop downstream patch after all
<Ansuel>
the big thing i don't want an upstream patch is the PHY package thing... i don't want everyone to jump on that train and then DT changing stuff
<robimarko>
I wasnt talking about that, rather just the MDIO clock
<robimarko>
PHY package is too big to refactor our stuff just for upstream to take another direction
<Ansuel>
yep let me first resend the 8081 series since it seems they forgot about it and and i will just put those patch in pending
<robimarko>
Sounds great
<robimarko>
I will give the ipq60xx target another look over the weekend
<robimarko>
As Mantas upstreamed the USB fixes and the QDSS clock for wifi
<Ansuel>
still tempted to ask the guy to leave the ath stuff aside and handle it in another pr and merge just the other stuff
<Ansuel>
oh nice was just ready to ask if he needed help for that
<robimarko>
I am kind of leaning towards adding the target as source-only
<robimarko>
And then the board itself can be easily added
<robimarko>
I have 2 or 3 boards that are half ported anyway
<robimarko>
Its a pain to try and polish the target all at once
<Ansuel>
thing is that only wifi is problematic rest of the thing are o.k. right?
<robimarko>
Yes, that is the situation AFAIK
<Ansuel>
(anyway planning on putting all my efforts in the apcs driver and see what is the current problem with upstream/reworking it)
<robimarko>
APCS?
<Ansuel>
cpufreq and efuse
<Ansuel>
cpr ?
<robimarko>
I already upstreamed NVMEM CPUFREQ for ipq60xx
<robimarko>
But CPR is not upstream
<robimarko>
Konrad tried for like 14 revisions or so
<Ansuel>
but some version of it are already there... maybe i can try to contact him and see if we can somehow coordinate ?
<robimarko>
CPR currently in the kernel is for the QCS404 SoC
<robimarko>
Its way simpler version then the v3 and v4 we need
<robimarko>
We at least need v4 for the CPU block
<robimarko>
v3 is used for the NSS UBI cores
<Ansuel>
ugh... tought the situation was much better
<Ansuel>
so that guy that said "CPR IS FULL UPSTREAM FIX YOUR IPQ CODE 1?!?!?" was lying
<robimarko>
Can you link that?
<Ansuel>
telegram group was lots of month ago
<Ansuel>
they work on mobile stuff aka snapdragon related things...
<robimarko>
Yes, and one of them probably started the upstreaming
<robimarko>
Angelo something something
<robimarko>
And then Konrad took over
<Ansuel>
and now Konrad is a reviwer so MAYBE there is hope
<robimarko>
He was having issues with our favorite DT crowd
<Ansuel>
starting to see a pattern where things are getting more and more complex and DT guys asking for very simple nodes format...
<robimarko>
I kind of get their goal, but they are starting to get detached from reality
<robimarko>
I think I even added ipq807x one time to CPR but never tried it
<robimarko>
Cause half of the values are pure magic that I have no idea where to get
<Ansuel>
if we are lucky enough the implementation is the same of some snapdragon board
<Ansuel>
and if that's the case konrad can help
<robimarko>
We were not luckly
<robimarko>
I did ask Konrad and the Angelo something something guy
<robimarko>
Basically it was something we had to print, something we read from DTS, something from the driver etc
<Ansuel>
they recycled half the SoC but made a very custom CPR impelemntation? wth.....
<robimarko>
Unlucky for us, there was only CPRh implemented, no CPRv4
<Ansuel>
another hope is asking if the linaro guy have some contacts but that is HARD
<robimarko>
Indeed
<Ansuel>
i wonder... does ipq50xx have a similar implementation?
<Ansuel>
since they are pussing so much effort in supporting that family...
<robimarko>
I dont think that ipq50xx uses CPR at all
<robimarko>
Its way too simple to need it
<robimarko>
IPQ957x does though
<robimarko>
My plan is to now spam Linaro on every upstreaming attempt with why ipq6018 and ipq8074 arent included
<robimarko>
Then they at least publicaly promise to upstream them
<Ansuel>
hope they don't get pissed with it
jeff___m has quit [Remote host closed the connection]
<robimarko>
What are they going to do?
<robimarko>
Stop upstreaming stuff they are not upstreaming?
philipp64 has joined #openwrt-devel
<robimarko>
BTW, my CRS328 is driving me nuts
<robimarko>
The SFP+ port keeps flapping and my SFP GPON is there
<Ansuel>
(i pushed the mdio fix in pending)
<robimarko>
Awesome, let me open the Qnap PR
<Ansuel>
I assume I should do the same for nbg right?
<Ansuel>
to my surprise qsdk doesn't load the fw to the aquantia port was broken all this time???
<robimarko>
On the NBG?
<Ansuel>
yes
<robimarko>
Wait, it did not work in the stock FW?
<Ansuel>
yes it did... talking more of what we are shipping now... afaik we don't include the tool to load the firmware from userspace
<Ansuel>
and nobody does
<Ansuel>
soooo in the current firmware we build from buildbot the port si broken i assume?
<robimarko>
For the Qnap instructions tell you how to flash the firmware and make the U-Boot load it
<robimarko>
I assume its the same for the NBG
<Ansuel>
let me check...
<Ansuel>
mhhh nothing in instruction... also uboot doesn't load the fw with bootipq
<robimarko>
By default it doesnt
<robimarko>
For Qnap it was in the instructions, so basically the port did not work
<robimarko>
Well, that sucked
<Ansuel>
soo the way was to tweak the bootcmd to call the load_aq and then bootipq
<robimarko>
Yes
<Ansuel>
then yep i guess the port is broken on ngb
noltari has quit [Read error: Connection reset by peer]
<robimarko>
That sucked
<Ansuel>
well also the led driver is broken sooo...
<Ansuel>
nbg state is not that good currently
noltari has joined #openwrt-devel
<robimarko>
IPQ is in a weird state, its quite popular from the users
<robimarko>
But we lack devs
<Ansuel>
well some are dropping it due to the ath11k state
<robimarko>
Which is again due to lack of development
<Ansuel>
btw question
<Ansuel>
are we instructing people on flashing the fw on the ethphyfw ?
<Ansuel>
(partition)
<Ansuel>
cause if the case then we are doing something wrong as we are not accounting for the mbn header (making the load_aq not working)
<robimarko>
I can only say for Qnap its all in instructions
<Ansuel>
the fact that the gpio pin were reversed is lovely ahahah
<robimarko>
Indeed
<robimarko>
Luckily for us we are not really resetting the AQR
<robimarko>
So it worked
<Ansuel>
mhh did you tested if we can use dynamic partition instead of declaring fixed partition ?
<robimarko>
We cant
<robimarko>
As there is only one ethphyfw partition
<robimarko>
And its not large enough for both AQR FW
<robimarko>
BTW, reset-assert-us aint working for me to actually force a reset
<Ansuel>
deassert ?
<robimarko>
That is after you release it
<robimarko>
Our issue is that the reset pulse is not long enough to actually reset the PHY
<Ansuel>
btw how qnap works with loading the fw? only one port works?
<robimarko>
Not following?
<Ansuel>
smem have a single ethphyfw correct ?
<robimarko>
Yes, but the same FW is loaded to both AQR-s
<Ansuel>
and that is not correct?
<robimarko>
Yes, at least the LED-s are incorrect
<robimarko>
Stock FW has separate FW-s that are different for each port
<Ansuel>
and they were loaded from userspace right?
<robimarko>
Yes
<robimarko>
They have a script that calls aq-fw-loader
<robimarko>
And then sets the USXGMII MAC autoneg bit via SSDK
<robimarko>
Ok, so reset-assert-us works if set to 100ms
<Ansuel>
my concern is that i would still try to keep the mbn header just to keep uboot working (ethphyfw1 partition match the one from smem right?)
<robimarko>
But why?
<robimarko>
It will just keep working unless users decide to migrate to kernel loading
<robimarko>
And the FW instructions point to isnt one from the stock FW anyway
<Ansuel>
boot interrupt if someone ever wants to debug anything?
<robimarko>
I dont see how this would help
Grommish has joined #openwrt-devel
<Ansuel>
let me explain it better
<Ansuel>
uboot loader expect the header to be present at the start of ethphyfw and assume the firmware right after it. In our custom partition table, we introduce a second partition with it and we flash both partition without the MBN header. Uboot way to load the firmware won't work. (if we want to keep both we can at least keep the MBN header in the first partition and declare the NVMEM cell at an offset)... It's just for the sake of keeping the port working
<Ansuel>
in uboot
<robimarko>
I get that, but I dont see an advantage
<robimarko>
From the factory there is no FW in that partition nor is U-Boot used to load the FW
<Ansuel>
well yes indeed the port was broken anyway from uboot
<robimarko>
Adding MBN just adds a step users need
<robimarko>
Personally I find it way easier to just do mtd erase
<robimarko>
Then mtd write
<robimarko>
And then after a reboot AQR-s work
<Ansuel>
we can't redistribute them right?
<robimarko>
Nope
<robimarko>
I plan to update the wiki to prefer this install method
<robimarko>
It avoids the need to mess with u-boot or its env completely
<robimarko>
And its simple to point to the stock FW location for the original FW
noltari has quit [Read error: Connection reset by peer]
<robimarko>
You can simply scp it off the stock FW or unpack the upgrade image
<Ansuel>
on that matter i found a big modern tool to unpack stuff...
<robimarko>
Then on first OpenWrt boot you just write those to the partitions and after a reboot it works
<Ansuel>
unblob (much better than binwalk)
<Ansuel>
anyway ok i get your point... uboot will just fail on crc calculation so it's not a problem having stuff in the ethphyfw partition
goliath has joined #openwrt-devel
<robimarko>
It wont as by default it doesnt care, it doesnt call the aq_fw_load
noltari has joined #openwrt-devel
<Ansuel>
even when boot is interrupted?
<robimarko>
Yes
<Ansuel>
they disabled that interesting
<robimarko>
The default bootcmd just calls bootipq
<robimarko>
We added the aq_fw_load
<robimarko>
As there was no way to load the FW other than that
<robimarko>
Ugh, unblob fails building with pip on Fedora 39
<Ansuel>
:(
<Ansuel>
maybe you are missing some extractor?
<robimarko>
Nope, wheel is failing for lief
<robimarko>
But I can just use the docker version of unblob