skynet2 has quit [Quit: Leaving]
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_sunxi.html has been updated. (0% images and 100.0% packages reproducible in our current test framework.)
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
minimal has quit [Quit: Leaving]
damo22 has quit [Quit: Leaving.]
damo22 has joined #openwrt-devel
<damo22> if the rootfs is 0xfa0000 in size, do i make the IMAGE_SIZE := 16000k ? uboot is having trouble decompressing the initramfs+kernel
damo22 has quit [Quit: Leaving.]
damo22 has joined #openwrt-devel
<damo22> i tried not using lzma to compress the kernel, i just used the vmlinux-initramfs file and tftpbooted that and i got somewhat of an early console, but it crashed early after printing CPU type
<damo22> maybe i was missing the dtb?
damo22 has quit [Read error: Connection reset by peer]
damo22 has joined #openwrt-devel
<damo22> i appended the dtb to the vmlinux-initramfs image and it booted
<damo22> but i turned off initrd compression
<damo22> what do i do now?
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<owrt-images-builds_> Build [#222](https://buildbot.openwrt.org/images/#/builders/219/builds/222) of `master_ath79/generic` completed successfully.
goetz has joined #openwrt-devel
goliath has joined #openwrt-devel
fossdd has quit [Remote host closed the connection]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
robimarko has joined #openwrt-devel
<damo22> if it booted just with "tftpboot 0x8000000 vmlinux-initramfs-dtb" does that mean i dont need to wrap it up in a tplink-like firmware?
<stintel> Mangix: since you seem to be looking at GCC 14 compile issues, your thoughts on https://github.com/stintel/readsb-protobuf/commit/b2b215cc69677c30f7ba17a90afefb4e1d44e055 ?
<damo22> reads beard
<damo22> i dont understand what u-boot expects to see. mktplinkfw2 seems be a tool that prepends a header to the top of the firmware that is tplink specific...
<damo22> but my vendor u-boot seems to boot a plain kernel + initramfs + dtb, can i just use that?
<jow> stintel: the error in the commit message makes no sense
<jow> stintel: the original code does not cast, and the rrd.argv expression is a char *[] (char **)
<jow> stintel: so where is the `(const char *)` in the quoted compiler error coming from? Maybe from an earlier fix attempt of yours?
<stintel> no, I have that error on the upstream dev branch
<jow> off_t offset = 0;
<jow> sorry
<jow> no (const char *)
<jow> in line 219
<stintel> jow: I added that cast to fix the error
<stintel> the error does not appear with my code, it does with the code you linked
<jow> okay but then the error you quoted in your commit message:
<jow> readsbrrd.c:219:43: error: passing argument 2 of ‘rrd_create’ from incompatible pointer type [-Werror=incompatible-pointer-types] 219 | rrd.status = rrd_create(rrd.argc, (const char *) rrd.argv);
<jow> is wrong, it refers to code after you applied an incorrect cast
<jow> it should read
<jow> rrd.status = rrd_create(rrd.argc, rrd.argv);
<jow> and not
<jow> rrd.status = rrd_create(rrd.argc, (const char *) rrd.argv);
<jow> there is no
<jow> `(const char *) rrd.argv`
<jow> in the upstream code
<jow> just
<jow> `rrd.argv`
<stintel> that's what I'm saying
<stintel> upstream code does not build
<damo22> char *argv[MAX_RRD_ARGV];
<stintel> my change fixes that
<jow> stintel: yes it does but the error message you quote as reason for your fix is incorrect
<jow> the original (broken, not compiling) code in line 219 is `rrd.status = rrd_create(rrd.argc, rrd.argv);`
<jow> your error message claims it is `rrd.status = rrd_create(rrd.argc, (const char *) rrd.argv);`
<stintel> oh wait
<stintel> copied the wrong error
<jow> this makes judging the fix commit confusing :)
<stintel> sorry
<stintel> and thanks for checking
* stintel realizes he skipped coffee
<stintel> but is it a clean fix (I'd say it's a lazy fix :P)
<stintel> but you can't malloc a const char *argv[MAX_RRD_ARGV]
<jow> correct
<stintel> so it would need a helper function maybe
<jow> the cast is correct
<jow> the intent of the const char ** in the function is to signify that it does not alter the vactor passed to it
<jow> *vector
<jow> passing a char * to function taking const char * also works fine
<jow> but passing a char ** to a const char ** taking one does not since a pointer to const char pointer is not the same as a pointer to a char pointer
<stintel> alright, thanks, I'll submit the PR
* stintel misses rust :P
<stintel> then the next error I can fix by adding -ltinfo after -lncurses but I suspect that might cause breakage when ncurses is not split in ncurses and tinfo
<stintel> and as there's no configure script ... how do I detect that
<jow> not easily
<jow> if all you have is a makefile, you need to perform a link test there and decide whether to add -ltinfo or not
<jow> but maybe it is simpler to just add -ltinfo to OpenWrt's package LDFLAGS
<stintel> does this look ok?
<jow> given that they already use pkg-config elsewhere, the fix looks like a sane upstreamable proposal
<stintel> this way of using pkg-config is already used in the Makefile
<stintel> alright, thanks again!
damo22 has quit [Quit: Leaving.]
<stintel> now I hope I spammed the guy enough to take the PRs and tag a new version so I can package it for OpenWrt without carrying patches ;)
<jow> sneaky
<stintel> :P
<stintel> and also create an ebuild for my gentoo overlay
<stintel> I'm actually running this program on a gentoo riscv musl host
<stintel> I should order a few more VisionFive 2 to run OpenWrt
<stintel> ahh but the 4GB version is sold out, the 8GB version is maybe a bit pricy
* stintel compares to rpi3
<stintel> I just like that it runs vanilla OpenSBI, U-Boot and Linux kernel
<stintel> wigyori: are you working on 6.6 support for starfive target?
<wigyori> stintel: started to - the vf guys promised that they'll bump up their sdk kernel to 6.6
<stintel> ah
<wigyori> that was promised for may - technically they still have 2 days
<stintel> well I had it running on vanilla 6.6 or 6.7 with only backports for the PCIe controller (which I suspect will land in 6.11)
<stintel> so probably bumping to 6.6 will greatly reduce the amount of patches for the target
<stintel> which is always nice
<wigyori> absolutely
<wigyori> same happened to d1 as well
<wigyori> gone down from 100+ patches to 15
<stintel> nice
<stintel> and while this thing is not quite fast, it's perfectly usable for a load of tasks
<stintel> it's currently handling my Zigbee network in my house
<stintel> do you happen to know if there is a compatible PoE module available for it? rvspace forum post seems to claim it's pin incompatible with the RPi PoE modules
xback has joined #openwrt-devel
<wigyori> haven't checked - but given the chinese community around it, i wouldn't be surprised if something pops up on aliex
<wigyori> talking about speed - i've got that new spacemit k1 board, the one with the 8-core, rva22-compatible soc
<stintel> me too
<wigyori> nice
<stintel> but the sdks are horrible (monster commits)
<wigyori> yep
<stintel> so upstreaming is going to suck
<wigyori> yep\
<wigyori> hehe, you're a couple days ahead of me ;)
<stintel> we could theoretically diff against upstream
<stintel> and add support in OpenWrt
<stintel> but it's going to be ugly ;)
<wigyori> plan to - but 6.1 wouldn't make too much sense probably
<stintel> ah but the sdk is 6.1
<stintel> so doing 6.6 is going to be virtually impossible
<wigyori> for now yes
<stintel> we could have it in a staging tree maybe
<stintel> and poke banana pi / spacemit to please do a 6.6 release
<stintel> and ask if they plan on actually upstreaming support
<stintel> the performance is actually quite nice
<stintel> I did some openssl speed benchmarks and iirc single core was ~2x the VF2
<wigyori> that's nice
<stintel> so if this thing gets upstream support, that might become a nice alternative to the raspberry pi with the weird GPU bootloader :P
<stintel> and a solution to stop sending money to broadcom ;)
<wigyori> the vf2 and the d1 was a nice try to get riscv to the devboard community with a reasonable price
<wigyori> this k1 will push it up a notch with its performance
<stintel> yeah, I really like the progress in RISC-V land
<wigyori> there are some perverse tries though, like that sg2002
<wigyori> that has a c906 riscv core as coprocessor, that's fine
<stintel> ah yeah the high core but no rvv ?
<stintel> rvv 1.0*
<wigyori> but there is a c906 riscv plus an a53 arm core, and you can select at boot time (by whatever means) which you want to boot the OS on
<stintel> ah this one
<stintel> hmmm
<stintel> I just realized I can do a routing speed test on the bpi-f3
<stintel> I'm in my house with limited equipment, but there's an ethernet interface in my monitor
AndyCap has joined #openwrt-devel
damo22 has joined #openwrt-devel
<damo22> i have a tplink header that is unrecognized by mktplinkfw or 2 or tplink-safeloader, should i paste the hex somewhere?
<stintel> and 500m CAT6a and some connectors, so UTP cables aren't going to be the problem :D
<damo22> i think i have discovered tplink header version 3
<damo22> 00020000 03 00 00 03
<damo22> its like its got two 16 bit values back to back in opposite endian for the version
<damo22> instead of one 32 bit value
<damo22> so i split the version field into two and tried to parse the file and got all the fields in the wrong endian
<damo22> using mktplinkfw2
<stintel> [ 5] 0.00-10.00 sec 852 MBytes 715 Mbits/sec 367 sender
<stintel> [ 5] 0.00-10.00 sec 850 MBytes 712 Mbits/sec receiver
<stintel> and that might be the VF2 being CPU bound
<damo22> is there a mailing list to discuss a port i am trying to do?
<damo22> there must be someone knowledgeable about the tplink wrappers
<damo22> here's the tplink header v3 i found in my image: https://zamaudio.com/mbox2/tplink-header-v3.txt and the full rom dump is here https://zamaudio.com/mbox2/mr200-factory.rom
<stintel> damo22: openwrt-devel or try the forum
<stintel> or wait for someone who's more experienced with the TP-Link stuff to appear here
moobsen has joined #openwrt-devel
<damo22> thank you
<stintel> ~760Mbps/~735Mbps, without NAT on the BPI-F3, seems to be at 100% ksoftirqd
<stintel> both end0 and end1 using the same CPU for IRQ
<stintel> and can't seem to change smp_affinity
<stintel> oh wait I can
<stintel> but the driver seems to ignore it
<stintel> ooh nice, ~870Mbps both directions
<stintel> end1 ignored the smp_affinity but end0 not
<stintel> wigyori: that's not bad
<stintel> end the ethernet driver supports almost no offloading
<stintel> I'd say looks promising
<stintel> but not sure I wanna run that sdk kernel on my main router in my house ;)
<stintel> I might just get another VF2 for that, with 2x gigE (I have only 1 with 1x gigE and 1x FE
<stintel> currently don't have a fast enough uplink here so would be a good option for now
<enyc> Hrrm, what Devel works/ideas are on the way for 'deplayment' config tools and so-on, ooi ?
<enyc> There may WELL be current good workable FOSS for this; I was wondering anyhow!
<enyc> e.g. Deploy 5* APs with particular set of VLANs/SSIDs/config, and centrally set the Channel frequencies, on a whoe load of AP55/AP100 with new OpenWRT ...
<enyc> I see OpeNWISP and other such things I"ll now look into, but was wondering on the Devel side hat 'abstractions' and so-on might be being put into place to assisnt
<stintel> so there's a datacenter less than 2km from my address but no fiber between there and here, and we need to cross a river so it will be not cheap
xback has quit [Remote host closed the connection]
<stintel> but I just requested a cost estimate
xback has joined #openwrt-devel
<stintel> if it's not too crazy I'm going to have to be looking at 10G capable hardware again :P
bwitte has joined #openwrt-devel
<wigyori> stintel: that's not bad, yep
<tmn505> damo22: https://github.com/xdarklight/mktplinkfw3, if I'm reading it right, using v2 header should suffice for U-boot to boot it (beacause it doesn't check signature)? I think checking TD-W8980 image recipe should give some hints how to approach this.
goetz has quit [Quit: goetz]
goetz has joined #openwrt-devel
goetz is now known as Guest7950
goetz has joined #openwrt-devel
<stintel> wigyori: I'm surprised by the onboard Wi-Fi on the BPI-F3
<stintel> rx bitrate: 1200.9 MBit/s 80MHz HE-MCS 11 HE-NSS 2 HE-GI 0 HE-DCM 0
<stintel> tx bitrate: 960.7 MBit/s 80MHz HE-MCS 9 HE-NSS 2 HE-GI 0 HE-DCM 0
<stintel> and I've seen ~500Mbps or so on iperf3
minimal has joined #openwrt-devel
<stintel> [ 31.913917] RTW: Realtek rtl8852bs WiFi driver (Powered by Spacemit,Ver v1.19.7.1-51-g48af265.20230922) init.
<Slimey> =)
<stintel> not impressed by the "Powered by Spacemit" spam
goetz has quit []
goetz has joined #openwrt-devel
* Slimey gets out the hexeditor
Guest7950 has quit [Ping timeout: 480 seconds]
goetz is now known as Guest7953
Guest7953 has quit [Read error: Network is unreachable]
goetz has joined #openwrt-devel
goetz has quit []
goetz has joined #openwrt-devel
cp- has joined #openwrt-devel
goetz has quit [Quit: goetz]
goetz has joined #openwrt-devel
cp- has quit [Ping timeout: 480 seconds]
goetz has quit [Read error: Connection reset by peer]
goliath has quit [Quit: SIGSEGV]
moobsen has quit [Quit: Page closed]
<stintel> ugh
<stintel> murrica
vincejv has quit [Remote host closed the connection]
dermoth has quit [Ping timeout: 480 seconds]
dermoth has joined #openwrt-devel
dermoth has quit [Ping timeout: 480 seconds]
xback has quit [Remote host closed the connection]
xback has joined #openwrt-devel
mark22k has quit [Quit: The Lounge - https://thelounge.chat]
mark22k has joined #openwrt-devel
robimarko has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
vincejv has joined #openwrt-devel
<Habbie> > reported that Arm was lobbying politicians for restrictions on RISC-V.
<Habbie> i was actually reading that exact article until i opened my irc client :D
<dwfreed> reminds me of my ISP
<dwfreed> instead of actually competing with FTTH, they just "bought" the property, so they're the only internet provider (except DSL, which, well...)
<Habbie> what property?
<dwfreed> apartment complex
<Habbie> -what-
<Habbie> that's amazing and terrible
<dwfreed> by bought, I mean paid off the landlord so they'd be the only ones allowed to provide service
<Habbie> oh got it
<Habbie> just terrible then
<dwfreed> yeah
<Habbie> reminds me of a story i read today, where a coffee shop opened near an office building, and the office building removed all free coffee machines
<Habbie> "you can go over there now"
<dwfreed> I don't drink coffee, but I would not go to that coffee shop at all just out of spite
<Habbie> same and also same
<dwfreed> (doubt it would help much, though)
<Habbie> in our office, there's a coffee machine, where i can pay by NFC (and it's not my money), including hot water
<Habbie> but our new neighbours just put a kettle next to it :D
<dwfreed> seems odd to charge for hot water
<Habbie> it's hot water, clean cups, a tea selection
<dwfreed> ah
<Habbie> on the coffee side, my manager is -super happy- we can just pay, like, 85 cents per cup and have no work
<dwfreed> definitely
<Habbie> and on the tea side, works out for me at least :)
tidalf has joined #openwrt-devel
bluew has quit [Quit: Leaving]
bluew has joined #openwrt-devel
tidalf has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gch981213 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
dansan has quit [Ping timeout: 480 seconds]
<Mangix> stintel: instead of casting, maybe try using &. rules regarding array decay are funky.