<djfe>
Some NBG6716 do not have ath10k calibration data in flash, only in chip OTP
<djfe>
in ar71xx they validated the length by checking the header on flash (essentially caldata_validate() nowadays)
<djfe>
But they did it before extracting the calibration data
<djfe>
I don't want to wear down the nand flash by extracting and deleting the empty caldata partition on every boot. What should be done here? it's ath79-nand
<djfe>
empty meaning it's mostly full of 1s
<djfe>
caldata_validate() currently requires the caldata to be extracted before being run: it reads the header/magic from /lib/firmware/$FIRMWARE (fixed path)
<PaulFertser>
[Pokey]: I wonder how come you decided to try it with "Client (WDS)" as the driver isn't mac80211-based it doesn't support 4addr mode. It shouldn't have affected the test results though. And another fellow on #openwrt reported same problem as you with this binary on raspberrypi3. So it looks like here's some essential difference in the base kernel, probably 5.10 used by OpenWrt doesn't handle
<PaulFertser>
something on the USB level compared to the latest raspbian you tried.
<[Pokey]>
PaulFertser: probably because I am a forgetful derp
<[Pokey]>
PaulFertser: Hmm, okay, I wonder what could be done here... I should ask, do you intend to bring this into OpenWrt as a package at all, or purely for this one instance you are building for my benefit?
<PaulFertser>
[Pokey]: I would consider trying to add it properly but if it doesn't really work on the most common target then it makes no sense.
<[Pokey]>
I am wondering if a newer kernel would fix it, and I haven't checked at all but I would assume the snapshot is a newer kernel?
<[Pokey]>
I also plan to try stock Debian tonight on the Pi, not sure that makes much difference to anything but I suppose if it works there too, that provides additional confidence in the driver at least
<PaulFertser>
[Pokey]: not much https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/bcm27xx/Makefile;h=e408c9040cd9e4168e1bf9fac81bc1a38a883b71;hb=HEAD#l14
<PaulFertser>
[Pokey]: probably when the target is migrated to 6.1 it's worth a retry.
<PaulFertser>
[Pokey]: the driver is crap either way :)
<[Pokey]>
PaulFertser: Fair! The driver claims to support 5.10, however the difference is 5.10 falls into the range of Realtek support, whereas 5.12 onwards is community support. Not sure how much difference that makes
<[Pokey]>
Either way, shame that it would need additional debugging. Thank you for spending the time to build the package for me
<PaulFertser>
[Pokey]: and OpenWrt version you tried is actually 5.10 but wireless subsystem is from 5.15.92.
<[Pokey]>
Backported, interesting, I guess that could have interesting side effects
<PaulFertser>
Yes, but OpenWrt is using backports for wireless drivers since like forever so it's solid enough. I had to patch out the checks for LINUX_VERSION_CODE inside the driver to make it think that it's on 5.15 rather than 5.10 and it was all building cleanly, without warnings.
<PaulFertser>
One last thing to try would probably be using exactly the same config preprocessor defines as the raspbian build is using. I'll about it a bit later.
Tapper has joined #openwrt-devel
<PaulFertser>
[Pokey]: please re-download from https://paulfertser.info/kmod-rtl88x2bu_5.10.176+cfbebf74-1_arm_arm1176jzf-s_vfp.ipk , I recompiled without "concurrent mode" enabled, who knows, might make a difference. The next idea would be to run make on raspbian with V=1 to see all the preprocessor command lines to try to reproduce them on OpenWrt exactly.
<[Pokey]>
PaulFertser: I'm currently at my work's office at the moment so I'll have to try it out tonight when I am home again I'm afraid, sorry!
danitool has joined #openwrt-devel
<[Pokey]>
I can certainly do a V=1 on the pi as well if necessary, though being a Pi 1 it'll probably take a few hours
<PaulFertser>
[Pokey]: cool
Lynx- has joined #openwrt-devel
<ynezz>
guidosarducci: S in CDN stands for Stable :P joys of cloud based computing, just get used to it rebase/force-push and move on
<ynezz>
guidosarducci: sure, we could add longer delays between those 3 retry attempts, but if you get 503, then something got likely broken. I'm quite surprised, that we don't sha256sum the download, it might be corrupted
Misanthropos has quit [Ping timeout: 480 seconds]
Misanthropos has joined #openwrt-devel
Tapper has quit [Quit: Tapper]
romany047 has quit [Quit: Ping timeout (120 seconds)]
robimarko has joined #openwrt-devel
<guidosarducci>
ynezz: what's to get used to? This hasn't been happening for years... started only a few days ago with the master/main and CI changes, and makes progress on PRs very difficult. Each rebase/force-push now seems to bring a new CI failure: e.g. now some checks are just "cancelled" in https://github.com/openwrt/openwrt/pull/12705.
<ynezz>
its is happening all the time
<robimarko>
CI has been crapping out regularly
<ynezz>
Canceling since a higher priority waiting request for 'Build Kernel-refs/pull/12705/merge' exists
<ynezz>
IMO CI is dead now
<ynezz>
page with information about the runners returns 500
<hellotherehello>
ynezz, i'mjust experimentingon my own..Can you link build guides? trying to compile nmap i openwrt on the latest version so i need many broken packages for that do work i reckon, where do i use some command to download all of them? Old packages and compiling don't seem easy
<ynezz>
openwrt.org has them
<hellotherehello>
ynezz, i'mjust experimenting on my own.. Can you link build guides? Just trying to compile nmap in openwrt on the latest version so i need many broken packages for that do work i reckon, where do i use some command to download all of them? Old packages and compiling don't seem easy.
<hellotherehello>
ynezz yes i'm aware, but could you be more specific?
<ynezz>
can you share some details about your build host? how many CPU cores do you use for compilation?
<hellotherehello>
Got any solutions?
<hellotherehello>
thanks
<ynezz>
there are known race conditions with python3 package
<ynezz>
so try `make -j1 nmap` and see if it helps overcome the issue
<ynezz>
make -j1 package/nmap/compile
<hellotherehello>
thanks, same with make -j1 nmap-full ? It's the nmap-full. Does that download all of the missing dependencies and such?
<hellotherehello>
make -j5 package/nmap/compile would also work but be faster right?
<hellotherehello>
is it the number of cou's?
<hellotherehello>
cpu's
<hellotherehello>
-j4
<ynezz>
sometimes just retry of the failed command helps
<ynezz>
those concurency issues are hard to reproduce
<ynezz>
it might be something else as well, I'm just wild guessing here
<hellotherehello>
ok thanks
<hellotherehello>
if not i will skip the package, but wanted to test it out on a router, seems cool
<hellotherehello>
because here is said: Sopalajo Jun '20 Solved: The nmap-full package is only available on OpenWrt v19 repository. Thanks you all for helping.
<hellotherehello>
seems interesting that the openwrt is very flexible. thanks for the help. Yeah i should, but mostly just testing it out i might not evenuse it.. just want to try and compile but it will work soon i reckon, thanks again for the answer
<hellotherehello>
i could just put the ipk in the packages folder if i can't get this to work also then soon. Well it's impressive with how flexible openwrt seems overall in compiling! Fun to try and learn some compiling.
<Ansuel>
ubuntu devel for some reason still didn't switch to gcc13
<ynezz>
fedora38 has 13.1.1
<ynezz>
it builds fine x86/64
rmilecki has quit [Read error: Connection reset by peer]
rmilecki has joined #openwrt-devel
<ynezz>
once time allows I plan to create (bi)weekly scheduled workflow to check build on ubuntu:devel and fedora:rawhide to find out what breaks in the future releases
<ynezz>
like that Make 4.4 foo recently
<Ansuel>
they would be full build? so packages workflow?
<ynezz>
yes
<Ansuel>
we should add some kind of notification or email to warn if these build fail or we would not notice them i think
<ynezz>
maybe have some issue for that purpose?
<Ansuel>
mh yes we can set to create an issue with the error
<Ansuel>
nice idea
<Ansuel>
there should be some actions for that already there
<aparcar[m]>
ynezz: where do you see the breakages?
<jakllsch>
dangole: arround? i'm trying to figure out why the PHY on my RTL8125B card isn't detected
<jakllsch>
i think it's due to local patches from you
<hauke>
ynezz: nice feature, please add arch Linux too they often also have recent tools
<hauke>
Ansuel: If that GCC bug is hitting us we can backport the fix
<Ansuel>
hauke nope we can't
<Ansuel>
host tool are broken
<robimarko>
ynezz: I am using Fedora 38, been since the start and so far only SSDK broke due to make 4.4 but its SSDK-s fault
<Ansuel>
i mean to prevent that kind of problem... we should use our own make but it's overkill honestly
<robimarko>
Nah, that is just more work than is worth
<robimarko>
Especially since make gets updated so rarely
<Ansuel>
ynezz do you have access to coverity? can you accept my request ?
<hauke>
Ansuel: done
<Ansuel>
thanks! curious to check those defects
minimal has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
Tapper has joined #openwrt-devel
rmilecki has quit [Remote host closed the connection]
rmilecki has joined #openwrt-devel
<Znevna>
you're all evil for not helping that dude with qsdk
<[Pokey]>
Would you like me to log the output of that to a file?
<[Pokey]>
It'll probably take a few hours
<PaulFertser>
[Pokey]: just few first .c files would be enough
<PaulFertser>
[Pokey]: also, building a single driver like that even on rpi is probably less than half an hour.
goliath has quit [Quit: SIGSEGV]
<[Pokey]>
PaulFertser: Okay, I will do as requested and obtain the output
danitool has quit [Ping timeout: 480 seconds]
<[Pokey]>
PaulFertser: https://pastebin.com/nBQ76zr5 Hopefully this is enough, let me know if it isn't. I just invoked make instead of the installer script
<PaulFertser>
[Pokey]: yep, that's what I wanted.
<[Pokey]>
Sweet!
<PaulFertser>
[Pokey]: would be funny if it's really -O2 vs -O1
<[Pokey]>
PaulFertser: I have personally experienced a difference between 2 and 1 being the difference between an MCU booting and locking up
<[Pokey]>
I do not doubt it
<PaulFertser>
No, I see -O1 is present in OpenWrt command too and it's later than -O2 so should override.
<PaulFertser>
[Pokey]: yeah, so when I was dealing with MCU firmwares I always tried working with -O2 right from the beginning, and during debugging too, to catch bugs as soon as they're introduced.
<[Pokey]>
Turned out to be a clock initialisation race condition in the vendor's HAL
<PaulFertser>
Heh, gotta love those vendors
<[Pokey]>
PaulFertser: They aren't that old, very receptive to the community and it is a very indev SDK, I don't blame them (Bouffalo)
<PaulFertser>
[Pokey]: is that the same vendor where Ralim can't find why some Pinecils can't boot with BLE enabled?
<[Pokey]>
PaulFertser: I'm not sure!
<[Pokey]>
Possibly
<[Pokey]>
PaulFertser: If it is the V2, the current one, thats a BL702 so yes
<PaulFertser>
[Pokey]: re realtek options, will check them tomorrow, but, again, I do not have much hopes about it.