<mrkiko>
nick[m]1234: how is the conversin proceeding? :D
<nick[m]1234>
Had other things to do. I will soon go on. The most challeging part is to force people to test the conversions.
<mrkiko>
nick[m]1234: ... clear.
<nick[m]1234>
did you already push your device as PR?
<mrkiko>
nick[m]1234: no, because in the end the conversion was made by robimarko, and as I understood, he will take care of that
bluew_ has quit [Quit: Leaving]
<mrkiko>
nick[m]1234: if youcan help me out keeping track of this with him, I would be grateful
<nick[m]1234>
just keep an eye on the sartura git PRs ;)
<mrkiko>
nick[m]1234: but the B2200 works - using it right now to send these messages, running DSA driver
<mrkiko>
nick[m]1234: sure
<mrkiko>
nick[m]1234: for now, I see no PRs for my evice
<nick[m]1234>
mrkiko: Maybe just do a PR. I think it helps robimarko
robimarko has joined #openwrt-devel
<mrkiko>
nick[m]1234: well, I should feel determined enough to do it from the CLI :D ... but then, in a more serious sense, I would end up doing a PR with only a patch authored by him :D
<mrkiko>
nick[m]1234: in case I'll contact him somehow ...
<robimarko>
No need for a B2200 PR
ecloud_ has quit [Ping timeout: 480 seconds]
<mrkiko>
robimarko: :D
<mrkiko>
robimarko: thanks a lot!
<mrkiko>
robimarko: I also sent a mail for board files inclusion on the ath10k ML as suggested by chunkeey, hoping it goes well, don't know if someone subscribed to ML has smore insight in the process
<robimarko>
Well, its just waiting time after its been sent
<robimarko>
Last time it took Kalle over a year
<Grommish>
robimarko: Hey, sorry I missed you earlier. Yes, they were LLVM feature flags
<robimarko>
Grommish: Hi, ok, I thought so
<robimarko>
Only one that I am not sure is -D32
<Grommish>
I'm getting them based on the default tuple defines for armv7 and the FEATURES flags in OpenWrt
<Grommish>
I think that has to do with the bitwidth. i know there is a -d16 as well
<robimarko>
Its usually for the FPU bitwidht
<robimarko>
Cause VFPv3 came in 16 and 32 bit variants
<robimarko>
Hence vfpv3-d16 and vfpv3-d32 in GCC
<robimarko>
But VFPv4 does not have such an option
<Grommish>
The entire arm organization tree is a misnomer for me heeh, Ill have to dig thru the tables and see.. Thanks!
<robimarko>
According to GCC ARM
<robimarko>
I think that D32 is implied if VFPv4 is selected as its the only option
ecloud_ has joined #openwrt-devel
<robimarko>
So, +D32 should be used probably
<Grommish>
I don't set a default feature instruction set hmm
<Grommish>
and, I found out LLVM doesn't recognize vfpv, its vfp, which means even more conversion
<Grommish>
eg vfp3 vfp4 vfp2 not vfpv3 etc
<robimarko>
So nice of them
<Grommish>
I went in with zero knowlledge and have gotten slightly better, but looking at things like vfpc4-neon.. Trying t figure out if it mean +vfp4 +neon or actually +vfp4 -neon, etc
<Grommish>
and the default examples I'm working with weren't much help in the OpenWrt environment, since they almost never line up anyway
<Grommish>
LLVM identifies the arm5 mpcore as a armv5tej for example, and expects it to be reported that way.. and mpcore is split between mpcore with FPU and mpcorenofpu without
<robimarko>
I suppose + means its there
<robimarko>
- disable it
<Grommish>
Well, that's the naming convention, but OpenWrt uses FEATURES=vfpv4-neon
<Grommish>
in the target Makefile/target.mk
<robimarko>
Yeah, since thats a GCC option
<Grommish>
So, does that mean NEON is disabled? or that is has NEON
<Grommish>
Things like that I'm still trying to figure out
<robimarko>
That means its has NEON
<robimarko>
You have to look a the GCC docs
<robimarko>
Its all nicely laid there
<Grommish>
Meh.. I was afraid of that.. It's another system to dig thru
<Grommish>
I did arbitrarily decide that if the FEATURES list NEON, it's enabled, otherwise its not
<robimarko>
That should be correct
<robimarko>
As in GCC you turn features on, not off
<Grommish>
and since i"m not defaulting any features, I can/need to outline them at build time per target, although I can supply the cpu to help
<robimarko>
Well, that thing doesnt really help
<robimarko>
As in ARMv7 most things were optional extras
<robimarko>
Best to look at the current GCC setting and look for the LLVM counterpart
<Grommish>
Yes, but thats because ARMv7 covered a willy-nilly let anyone decide what they want to use arch it seems depending on whoever was orering the chip
<robimarko>
Well, those are optional features
<robimarko>
So, you had to pay a license for it
<Grommish>
*nod*
<robimarko>
BTW, Wasnt Rust getting a GCC frontend?
<Grommish>
Dunno, I heard something about it, but it was "future"
<Grommish>
along with GCC handling ebpf
<robimarko>
Well, if they want to get rust into kernel its gonna need to happen
<robimarko>
eBPF is in GCC12
<robimarko>
AFAIK
<Grommish>
I don't build out ebpf in my LLVM because there is already support for it
<Grommish>
Just the other archs, but its a good thing I didn't try and tie nto the existing llvm ebpf support since it'll probably go away :D
<robimarko>
Well, everybody is looking forward to getting rid of LLVM to reduce the build time
<robimarko>
GCC should already have eBPF support, no idea whats the state of it though
<nbd>
i don't think gcc can be used to compile ebpf for openwrt any time soon
<nbd>
even when the backend is stable
<nbd>
not because of gcc, but because of the bpf kernel header mess
<robimarko>
Ok, I am not really familiar with it
<robimarko>
More precisely, I keep away from BPF
<Grommish>
I initially tried to change the existing LLVM eBPF in OpenWrt for what I needed, but turns out rust uses an enhanced LLVM anyway, so was a waste of time to persue
lelux has joined #openwrt-devel
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
f00b4r0 has joined #openwrt-devel
<f00b4r0>
Hmm. So it looks like older Yuncore A930 use a different uboot env size than the newer ones. Only way I can explain the bad CRC errors I see there. *sigh*
<f00b4r0>
hmm no, that's not it. wth
<mrkiko>
robimarko: I was NACKed fast, let's see how it goes with the new submission
<robimarko>
grift: Its more a matter of making the device be able to boot larger images than reducing the size of images
<grift>
i see
<robimarko>
mrkiko: zImage is great if the bootloader supports it
<robimarko>
As then kernel unpacks itself
f00b4r0 has quit [Quit: brb]
<mrkiko>
robimarko: BTW - do you remember where we discussed the sizel imits of some ipq40xx devices? Or is there any way i can deduce the size limit of the bootloader of the gl-b2200 ? I remember having reported it somewhere - but I may be wrong. Can't find it right now
<robimarko>
There was a PR or something for GL-inet devices
<csrf>
in one of the replies, u mention that a user mistakenly blew away the radio calibration data because he messed up when flashing the fw
<csrf>
is this data something that's stored in the bootloader partition? if not, where is it? I want to attempt building a new bootloader & custom openwrt fw image for this router, and would appreciate some help/advice
f00b4r0 has quit [Quit: brb - testing new device support on home router :)]
<robimarko>
Ahh, its been a long while since I touched the 840
<robimarko>
But as far as I can remember, it had an issue in which some of them arrived with bootloaders for the 8MB v4
<csrf>
yeah, i saw that reading thru your initial comments
<robimarko>
And if you then tried flashing anything using TFTP it would overwrite everything on the NOR as it wrapped around
<csrf>
I'm actually going to physically swap the flash chip for a 16MB, but I want to get things in order before I try a custom build
<csrf>
right now, I want to revert back to stock from your LEDE image. Do I simply tftp the full stock fw, or do I have to edit it (some ppl mentioned hex-editing the oem fw image, but not sure if it's necessary)?
borek has quit [Quit: borek]
<hanetzer>
yee. I like FIT images tho. really easy to boot :)
<robimarko>
csrf: I dont really remember
<csrf>
robimarko, ok no worries. any ideas on how the calibration stuff is stored, or how I can avoid wiping it out if I create a custom bootloader & openwrt image?
<robimarko>
I think there is a partition for it
<robimarko>
But like I said, its been years
<csrf>
ok, i'll take another look at it. thanks anyways
rua has quit [Quit: Leaving.]
srslypascal is now known as Guest3375
srslypascal has joined #openwrt-devel
Guest3375 has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
mattytap__ has quit [Read error: Connection reset by peer]
* f00b4r0
still can't quite figure which menuconfig settings trigger a near complete rebuild of world when only changing a DTS :P
f00b4r0 has quit [Quit: brb]
srslypascal_ has joined #openwrt-devel
srslypascal is now known as Guest3377
srslypascal_ is now known as srslypascal
Guest3377 has quit [Ping timeout: 480 seconds]
dedeckeh has quit [Remote host closed the connection]
guerby__ has quit [Remote host closed the connection]
guerby__ has joined #openwrt-devel
mattytap__ has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
Borromini has joined #openwrt-devel
f00b4r0 has joined #openwrt-devel
<f00b4r0>
well after quite a bit of fiddling, I now have a clean PR for the RB hAP ac lite (#9825)
<f00b4r0>
testing on my installed router made that a lot more "fun" ;P
<zorun>
f00b4r0: it was never ported to ath79 until now?! I thought it was
<f00b4r0>
zorun: it wasn't. There was a lingering PR opened in aug 2021, but the author went MIA
<f00b4r0>
so I got tired of waiting and decided to fix this myself. Also because I don't want to retire that device now that 19.07 is EOL'd :)
<zorun>
I see, aug 2020 even (from the link in your pull request)
<f00b4r0>
yeah I meant 2020 sorry
bkallus has quit [Remote host closed the connection]
bkallus has joined #openwrt-devel
<f00b4r0>
last author comment is from aug 2021. Anyway, now it's done :)
<zorun>
do you need testing? I think I got one "somewhere" in my mess :p
<f00b4r0>
you're welcome to test sure, but I've only posted after testing on my own device (which is why I was offline, it's my current router): it works :)
<f00b4r0>
I checked MACs, LED polarity, switch port numbering, pretty much everything
<f00b4r0>
booting master from initramfs can be tricky depending on your bootloader: you don't want too big an image
<f00b4r0>
mine seems to choke above 5.3MB
<zorun>
good then
<zorun>
oh, that seems annoying... from what I can see, release initramfs for ath79/mikrotik are around 6 MB...
<f00b4r0>
yeah. AIUI it varies from device to device. We had the same issue with one of the more recent RB merge IIRC
<f00b4r0>
#4176 in fact.
<f00b4r0>
for the hAP ac, unsurprisingly
<f00b4r0>
zorun: I'm thinking a way out could be to backport RB devices to 21.02 as much as possible (fortunately it shouldn't be overly difficult as we use a couple DTSIs for all of them), as the 21.02 initramfs is still within limits, from what I can tell. Then we could suggest using this to netboot before flashing the final image
<f00b4r0>
seems easier than hacking the build system to generate an initramfs that's different from the sysupgrade image