<neggles>
it would be super duper nice if someone could take another look at https://github.com/openwrt/openwrt/pull/4517 (ath79, adding device support) now that i've found the USB power control GPIO
<dvn>
PaulFertser: thanks
<neggles>
it's been sitting around for a while now due to some disagreement over name of LED DTS nodes
<neggles>
which does not seem to have come to a conclusion
<PaulFertser>
dvn: it just tells that when /etc/rc.d symlink is created it'll have number 99, that is the last one.
<dvn>
PaulFertser: thanks. and STOP=10 ?
<PaulFertser>
dvn: same about K10
<PaulFertser>
dvn: the order of stopping when the system shuts down.
<aparcar[m]>
Anyone compiling OpenWrt on a M1 CPU?
<hauke>
aparcar[m]: OpeNWrt compiles for me on Ubuntu running on ARM64
swalker has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
dangole has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
minimal has joined #openwrt-devel
dangole has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
isak has quit [Read error: Connection reset by peer]
<aparcar[m]>
hauke: I guess it’s the issue to use both Arm64 and macOS at the same time
<aparcar[m]>
Currently it fails mentioning some undefined symbols for the architecture
valku has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
<hurricos>
neggles: > Third device does not contain calibration data
<hurricos>
should I buy one of these devices and try to find how it's being done in OEM?
<hurricos>
I've been on the hunt for good OpenWrt 11ac devices for the last couple of months, so I'm interested
<hurricos>
Sorry, I went on a tangent. To your original question: don't worry, you're not being ignored, PR review is just backed up right now :^)
<hurricos>
Your PR looks very clean. If I can get my hands on some devices I will build and run-test and ACK, in my experience adrian usually focuses on the stuff that multiple people are looking at
<hurricos>
or, well, the conversation looks clean.
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<spacewrench>
Is there a reason the native GCC version doesn't keep up with the cross-compile GCC version? On my target (Mediatek MT7688 / Onion Omega2+) the cross version is 11.2, native is 7.4.
<spacewrench>
Hmm, maybe it's harder to cross-compile GCC...maybe it wants to compile some of itself during bootstrapping, and that's a weird dance in cross-compile land
<spacewrench>
I guess I can always compile 11.2 on the OpenWrt board itself.
isak has joined #openwrt-devel
<hurricos>
spacewrench: If you need a particular GCC version, pick the right OpenWrt version.
<hurricos>
wait, why do you need 7.4?
<hurricos>
(do you need 7.4?)
<hurricos>
oh
<hurricos>
wait I see what you mean; you want GCC to run on the Onion Omega2+?
<hurricos>
> compile gcc ... that's not going to happen, genautomata takes 400-500MB.
<hurricos>
It took 4 days for my MX60 to compile gcc under a gentoo chroot, of which 2 of those days were about digging deep into swap for genautomata to compile
<hurricos>
Are you trying to compile something specific that isn't a package?
<hurricos>
Or are you trying to compile a part of your own toolchain?
<hurricos>
For the latter, I'd be curious what you're doing. For the former, just use the cross-compiler toolchain by exporting some shell variables and just using the existing toolchain; better, create a package
<hurricos>
> 4 days ... MX60 < the device has 512MB of DDR2
isak has quit [Read error: Connection reset by peer]
isak has joined #openwrt-devel
philipp64 has quit [Quit: philipp64]
philipp64 has joined #openwrt-devel
<spacewrench>
hurricos: I just wondered why it wasn't the same version between the cross & native environment. Anyway, you're right: I really need to learn to use the cross environment. I tried compiling a simple Boost app on the Omega2+, and it took FOREVER! (I just included one of the Boost header files, and it churned on and on.)
<hurricos>
yeah, haint made for compiling :^)
<spacewrench>
I compiled linux natively...it took most of a day. And then I couldn't boot it.
<hurricos>
I don't really know why OpenWrt provides gcc as a package tbh
<hurricos>
it's certainly not made to self-host
<hurricos>
if you REALLY need a specific version, I always recommend just getting a gentoo chroot
<hurricos>
but like, why
<hurricos>
lol
<hurricos>
You'd do just as well to run the malta target in qemu
<hurricos>
fwiw
<hurricos>
though I've never had SMP working, likely because malta's not meant for that
philipp64 has quit [Ping timeout: 480 seconds]
<spacewrench>
Actually, I benchmarked qemu...on a good x86 machine, compiling lua in an emulated MIPS was about as fast as compiling it on the real MIPS. A Mac M1 was only a little bit faster. (M1 QEMU for ARM is pretty zippy, though.)
<hurricos>
Oh, cool!
<spacewrench>
It's amazing that it works as well as it does, but it's too slow to use in a development cycle. I don't even know whether they make regular PCs with MIPS processors.
<spacewrench>
I guess they do; and you can probably get time on one on the GCC compile farm. Maybe I should look into that.
<hurricos>
They do, Longsoon :^)
<hurricos>
but you still need cross compilation, different MIPS variant
nlowe has joined #openwrt-devel
<hurricos>
OK, time to try to inject lorem ipsum into the kernel ring buffer
<hurricos>
kernel *log* ring buffer
<hurricos>
and by inject, I mean compile in. Wow, that's a lot less interesting now that I put it that way.
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<stintel>
spacewrench: 7.4 just the version that is in OpenWrt-packages, it's been bothering me too
<hurricos>
but why .... would you have GCC on openwrt?
<hurricos>
I guess llvm bpf stuff is going the same way :\
<stintel>
to play around - I used it on my m300 to do so asm poking
<hurricos>
ah
<stintel>
sometimes you really need that to figure out stuff about the device / cpu
<hurricos>
OK, that's fair ...
<stintel>
so I was wondering, since OpenWrt runs on multiple targets with plenty of storage
<stintel>
should we make it possible to install toolchain & headers as ipk
<stintel>
and I am leaning towards "yes"
<hurricos>
imagine my shock when I find my lorem ipsum isn't in my kernel
<hurricos>
oh
<hurricos>
because I added it to patches-5.4
<hurricos>
stintel: I think any extensibility like that *has* to be merged in with official ways to extend the userland
<hurricos>
IMO the only reasonable way to replace the OpenWrt userland is in a chroot or, better, container
<hurricos>
when I say "replace the userland" I mean all of the work that will be required to make build systems in general happy
<hurricos>
I don't believe the toolchain is compiled with a musl-compiled GCC
<hurricos>
e.g.
<stintel>
just a thought, have not looked at specifics at all
<hurricos>
gotcha for sure
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
<Grommish>
f00b4r0: Probably :D But, it was an easy solve by just ignore PPC for now ;)
<f00b4r0>
Grommish: without looking at the code I can't say for sure what's going on, but my bet is that there's been a copy-pasta that mixed ppc instructions with x86 register monikers.
<f00b4r0>
Grommish: on ppc registers don't have names like rax and rdx. That's an x86ism
<Grommish>
f00b4r0: According to the rust devs, PPC under LLVM has been a pain and sore point for a whole
<Grommish>
and it's certainly beyond my skills, so I'll ignore it until I have nothing else to do heeh
<Borromini>
Grommish: you got 5.10 running fine on your Octeon device(s) don't you?
<Grommish>
Borromini: Not anymore.. 5.10/5.15 had massive kernel memleaks I was trying to chase down
<Grommish>
I've not been back in Octeon land to check the patches I've been shown to see if I might help or not
<Borromini>
Grommish: ok. pesky thing is my ER4 is in production so a bit hard to swap out/use as a guinea pig
<Grommish>
Right I've got multple Shields, both are running 5.4 without issue
<f00b4r0>
(the ppc cache invalidation routine at the end, that is)
<Borromini>
Grommish: yeah no issues there :)
<Grommish>
but rust-lang came back around (apparently people are like.. wiating for it?)
<Grommish>
and I was tired of watching RAM crawl by the second
<f00b4r0>
Grommish: anyway, I'm not really interested in rust tbh, but the file I linked is correct and should build fine. What you have is probably garbage, judging by the error messages. I hope this helps :)
<Grommish>
f00b4r0: From what I understand, rust-lang pulls LLVM from github as a sub-module, but I'll go look. I do appreciate the help!
<stintel>
that reminds me I have to get new winter tyres, have to look extra hard for the version with W speed index
<stintel>
having to set a warning on 240kph is annoying
<hurricos>
> 240kph < o_O
<stintel>
car can do > 300kph in theory
<hurricos>
oh
<hurricos>
car, OK :D
<PaulFertser>
You want to go in winter faster than 240 km/h?
<PaulFertser>
:-O
<stintel>
PaulFertser: winter tyres are kind of obligatory in several countries starting from November
<stintel>
doesn't mean it's going to be freezing cold when I'm on the autobahn
<stintel>
so yeah I've hit that 240 kph warning numerous times with the winter tyres
<PaulFertser>
stintel: in Germany or somewhere closer to where you live? ;)
<stintel>
autobahn == germany
<stintel>
and I'll most likely be driving to Belgium for the holidays, so .. :)
<PaulFertser>
Awesome, have a nice trip.
<stintel>
now there's another problem :P the car is normally limited on 250, but mine isn't, unfortunately the speedo stops at 260, and I doubt I can set the warning any higher than that :P
<stintel>
W = 270 and that's the highest I could find for the winter tyres
<stintel>
so... I should write an Android app that warns me at 270 on GPS? :P
<stintel>
PaulFertser: thanks
<stintel>
hadn't done autobahn for > 1y due to covid
<stintel>
had to get used to >240 again
<stintel>
now the engine has new conrod bearings and improved oil sump and oil pump, it's time to get a 3rd set of wheels for (semi-)slicks and improve my track times
isak has quit [Quit: leaving]
Borromini has left #openwrt-devel [#openwrt-devel]
isak has joined #openwrt-devel
nlowe has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
<hurricos>
to avoid further self-harm I am also going to buy a AP3710i and confirm that it still boots on openwrt master
<hurricos>
unless @blocktrron can confirm as much, of course
Acinonyx_ has quit [Ping timeout: 480 seconds]
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jow>
nbd: won't that break a lot of existing wireless configuration when upgrading from 21.02.1 to 21.02.2 ?
<nbd>
no, it's backwards compatible
<jow>
ok
<nbd>
compatibility is implemented in netifd-wireless.sh
<nbd>
it translates the existing option into the band option
<jow>
allright
nlowe has joined #openwrt-devel
nlowe has quit [Read error: Connection reset by peer]
<neggles>
hurricos: I suspect generating the 3rd chain caldata would require some rather fancy equipment - at least a decent 6GHz spectrum analyser? - but if there *is* a relatively simple way to unlock chain 3 that would be pretty great; I’d offer to send you one but shipping from here is probably more expensive than buying one locally now they’re effectively EOL/EOS with sophos
<hurricos>
neggles: I'm figuring that if the oem device has caldata, we have caldata.
<neggles>
as best I can tell it’s got two chains worth of caldata despite being 3 chains of device
<hurricos>
so what does the vendor fw do to provide caldata to its driver/
<hurricos>
I'm guessing copies one to the other and calls it a day?
<hurricos>
Figuring that bit out is what I'd like to do
<neggles>
it’s a QCA9880 for 5GHz yeah, the caldata bin is in the ART partition
<hurricos>
can you dump me the bin and shoot me a board photo?
<neggles>
sure
<hurricos>
paste.c-net.org is fine
<hurricos>
or wherever else
<neggles>
both ART entries only have caldata for 2x2, it seems - I couldn’t find anywhere in the OEM firmware that did anything different with an AP100 vs AP55
<hurricos>
you would also want to check the rootfs
<hurricos>
I see what you mean by third chain
<hurricos>
vendor might not use the third chain
<hurricos>
:P
<hurricos>
board photo
<hurricos>
would tell us for sure whether they intended not to*
fda has quit [Ping timeout: 480 seconds]
fda has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
<hurricos>
Let's go back to the cleaner fdt and try again
Luke-Jr has quit [Ping timeout: 480 seconds]
hurricos has quit []
hurricos has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
spacewrench_ has joined #openwrt-devel
spacewrench has quit [Read error: Connection reset by peer]
<neggles>
hurricos: here's a full OEM flash dump split into the various partitions & named appropriately: https://paste.c-net.org/CheckingPelvis - this is an AP55
<hurricos>
thank you neggles; I'm going to keep hacking on AP3825i, so I probably won't have time to look tonight, but ...
<hurricos>
definitely push the ART from that fw through apeethmgr
<neggles>
hurricos: no problem :) yeah i'm about to heh
<hurricos>
atheepmgr*
<neggles>
it has the 2.4GHz fw @ 0x1000 and the 5GHz fw @ 0x5000
<neggles>
which is fairly standard it seems
<hurricos>
very, that's identical to how I've always seen 'em
kenny has joined #openwrt-devel
spacewrench_ has quit [Ping timeout: 480 seconds]
spacewrench has joined #openwrt-devel
<neggles>
hurricos: oooooooo.
<hurricos>
?
<neggles>
heh, sorry, jumped the gun a bit, should've made the gist first