<angelsl>
if a device got merged in the past few days, will it make the 21.02 stable release?
<slh>
in general, no. openwrt-21.02 was branched off at the end of february, what was in master back then, is in - what wasn't merged by then, won't be. there are obviously exceptions (in the form of backports/ cherry-picks) for 'simple' cases (as in dts, image recipe and a couple of lines for ART extraction, network interface setup and LED configuration), but anything larger is rather unlikely (rt3200/
<slh>
e8450 support for example would be rather unlikely)
<angelsl>
i think my device falls into that - can i ask for it to be cherry-picked into 21.02?
<slh>
and yes, that one should be (more than-) trivial enough
<angelsl>
thanks :)
Grommish has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
rmilecki has joined #openwrt-devel
nitroshift has joined #openwrt-devel
tchebb has joined #openwrt-devel
decke has joined #openwrt-devel
feriman has joined #openwrt-devel
<ynezz>
angelsl: simple cherry-pick should do? can you test it?
<ynezz>
angelsl: I mean, `git cherry-pick -x b232680f847f4ea8d058849a51dedebb8e398a01` went fine, so just wondering if it's enough for having complete support for this device or some other commits in master are needed as well
<angelsl>
ynezz: let me get back to you
<angelsl>
someone else tried that and said they had wifi issues (stuck at 802.11g rates), but i haven't had time to see why
<angelsl>
i didn't expect any issues, since this device is virtually identical to EA7300v1/EA7500v1, which is already in 21.02
<ynezz>
I assume those wifi issues can be fixed later (if not HW related), for now its enough to know, that flashing the firmware wouldn't for example result in kind of bricked device or such
greearb has quit [Ping timeout: 480 seconds]
<angelsl>
ynezz: yeah, it flashes and runs fine
<angelsl>
are there any known issues around bad nand eraseblock handling?
<angelsl>
that was the only difference i could tell between my device and the other person's
<angelsl>
mine has none, his has a few -- although it booted fine either way
Zaba2 has joined #openwrt-devel
netprince__ has joined #openwrt-devel
netprince_ has quit [Remote host closed the connection]
greearb_ has quit [Remote host closed the connection]
<johnf>
both images are identical to binwalk, but the one produced using the default sysupgrade image behaviour is flashed differently by uboot and behaves differently
msva has quit []
<johnf>
is anyone able to tell me what the default sysupgrade image string is when you don't specify a value in the nand.mk file?
<johnf>
it must be something like, but slightly different from:
<PaulFertser>
johnf: I have an impression you are a bit cargo-culting with this work...
<johnf>
I can't disagree
<PaulFertser>
johnf: you need to understand why u-boot decides to flash your image to SPI NOR or to NAND.
<johnf>
so, it's fairly easy for me to produce a firmware image that can be flashed through uboot recovery, and that works properly
<johnf>
however, that same image will not work with sysupgrade inside openwrt
<johnf>
sysupgrade expects a tar formatted image (why, I don't quite know)
<johnf>
I can also create a tar formatted sysupgrade image that works, but when I do so my "factory" image in uboot bin format doesn't flash successfully
<PaulFertser>
johnf: probably you're still building it as nand target and that's why sysupgrade things it wants a tar.
<johnf>
yes, I am building it as nand
<johnf>
the device does have nand flash, and quite a lot of it
<johnf>
but the kernel gets too big for the partition if I enable support for it, and it's not critical for my needs
<johnf>
should I move this out of nand.mk and into ath79 generic
<PaulFertser>
johnf: in ath79/image/Makefile you can see how default sysupgrade.bin is generated.
<johnf>
which will probably work from both uboot and sysupgrade
<johnf>
hmm, ok, I see how that works and I've attempted to recreate it
<johnf>
it didn't work
<johnf>
I'm going to try to move this out of nand.mk and implement it as a generic ath79 device
<johnf>
as I haven't gotten the nand to work and it's not critical for my needs
<johnf>
I wish I knew more about this part of openwrt
<johnf>
I have three goals really: 1. be able to use the device 2. have support in openwrt 3. (optional) have functioning sysupgrade support
<PaulFertser>
btw, are you checking sysupgrade from OpenWrt upstream to upstream or from OpenWrt glinet to your upstream?
<johnf>
OpenWrt sysupgrade
<johnf>
I'm not concerned with being able to sysupgrade from gl-inet to openwrt, and this hasn't been possible with many of their recent devices
<johnf>
for instance b1300
<johnf>
needing to use uboot to get to stock is fine with me
<johnf>
I've moved my configs out of nand.mk and into generic.mk, stripped them down to the essentials
<johnf>
thanks very much for your help, I wish I didn't need so much of it
danitool has joined #openwrt-devel
<johnf>
this seems fairly promissing, working out a few dts issues but I should have something working soon I think
<PaulFertser>
johnf: good luck with that :)
<johnf>
I think it's actually working
<johnf>
install from uboot, sysupgrade from installed image
<johnf>
I've got some cleanup to do but should be able to submit a PR shortly
<johnf>
then we can find out what other mistakes I made ;)
JohnA has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
silver has quit [Quit: One for all, all for One (2 Corinthians 5)]
<nlowe>
Hmm, just updated to a current snapshot build on an R7800 - just using this as a dumb AP at MCS 9 (1300 Mb/s) I now get around 200 Mb/s instead of 500 Mb/s from a build a couple of months ago
<nlowe>
Something has changed
<nlowe>
It looks significantly regressed, investigating
JohnA_ has joined #openwrt-devel
JohnA has quit [Ping timeout: 480 seconds]
EqUaTe has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
JohnA_ has quit [Ping timeout: 480 seconds]
JohnA has joined #openwrt-devel
decke has quit [Quit: Leaving.]
<plntyk>
the imagebuilder is (again? still?) broken for 21.02-rc2 (and rc1) - snapshot imagebuilder works fine
<jow>
the handling of provides/conflicts in kconfig also seems to have changed
<jow>
I recall that at some point if e.g. ip-full was selected as <*> it was impossible to set ip to <*> as well, only to <M>
<jow>
now it is possible to set both to <*>
<jow>
which might explain some of the weird bug reports
<jow>
seems I misremembered, at least it behaves the same in 19.07
djStolen has joined #openwrt-devel
<djStolen>
Hi guys, short question. Are hostapd pkgs compiled with CONFIG_DEBUG_SYSLOG? It is set in all .config files of pkgs but trace in the log seems not to change once I change the setting on the running system as described here https://openwrt.org/docs/guide-developer/debugging
<PaulFertser>
djStolen: by default hostapd debug messages themselves are compiled out
<djStolen>
thanks. what is the best place to set CONFIG_DEBUG_SYSLOG?
<djStolen>
and will it use logd? or should i install syslog?
<PaulFertser>
djStolen: WPA_MSG_MIN_PRIORITY
<PaulFertser>
djStolen: hostapd already has CONFIG_DEBUG_SYSLOG enabled for all variants.
dedeckeh has joined #openwrt-devel
<djStolen>
WPA_MSG_MIN_PRIORITY in make menuconfig?
<PaulFertser>
djStolen: yes
<stintel>
you might also need to set something like this in /etc/config/wireless in the config wifi-device sections: option log_level '1'
<PaulFertser>
Yes, but it wouldn't do anything useful without recompiling with better MIN_PRIORITY
<djStolen>
yup, recompiling anyway. :-)
<djStolen>
oh, one more thing. make -jX is breaking at some point while -j1 goes through no problems.
<djStolen>
i guess some dependency while parallel compile
rejoicetreat has quit [Remote host closed the connection]
Zaba2 has joined #openwrt-devel
Borromini has joined #openwrt-devel
angelsl is now known as Guest1350
angelsl_ has joined #openwrt-devel
angelsl_ is now known as angelsl
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest1350 has quit [Ping timeout: 480 seconds]
<rsalvaterra>
Looks like getdns/stubby finally fixed the truncated DNS responses problem. About fscking time.