dgcampea has quit [Remote host closed the connection]
dgcampea has joined #openwrt-devel
cmonroe has quit [Ping timeout: 480 seconds]
cmonroe has joined #openwrt-devel
tohojo has joined #openwrt-devel
xes has quit [Ping timeout: 480 seconds]
xes has joined #openwrt-devel
iocampomx has joined #openwrt-devel
<iocampomx>
I've finally a working image of a custom-build OpenWRT build for a Mediatek SOC, a couple of times, the WIFI connection got lost (SSID disappeared) without any strange message on the kernel. I've seen some posts around the quality of the wifi driver. Anyone here can provide any advice on how to improve? Not sure if there are more than two drivers and/or if there is anything I have to fine-tune on the kernel menu.
<raenye>
anyone familiar with the Makefile system? I was trying to create a kmod package for the upstream hd44780 auxdisplay driver, and I needed unreasonable hacks to make it compile
<raenye>
specifically note the ugly way of converting package config to KCONFIG
Daanct12 has quit [Ping timeout: 480 seconds]
<raenye>
I also guess it makes sense to create separate kmod packages for charlcd (shared between multiple drivers) and for other drivers (e.g., lcd2s) but I only needed hd44780, so I put everything inside
<linusw>
raenye: it looks perfectly fine to me. Good job!
<raenye>
linusw: Thanks. but the annoying point is that there are quite a few displays in the kernel, and once CONFIG_AUXDISPLAY is set, it seems I must explicitly set all to no (as done in the commit above with lcd2s and the other one), or otherwise make/linux/compile will ask for them (and fail if it's make V=s)
<raenye>
So on my platform there were only two available drivers (others did not have the dependencies), and I don't want to manually set n to 20 others (nor to add kmod packages for everything)
<linusw>
raenye: Aha, have you tried to set it all explicitly to "# CONFIG_FOO is not set" in target/linux/generic/config-[5.15|6.1]?
<linusw>
Usually when we bring in a completely unselected new subsystem we have to set everything to default to n in those configs in order to not confont 6 million config ops.
<raenye>
linusw: that is indeed the missing point
<raenye>
I'll try that, thanks
<raenye>
how can I make sure I'm not missing any option?
<raenye>
(besides compiling on my platforms)
<raenye>
linusw: also, does it make sense to have everything under a single "auxdisplay" option?
<raenye>
similar to how kmod-sound works
<raenye>
you first enable general sound support, then all are beneath it
<linusw>
raenye: makes cognitive sense to me, that's how I'd do it.
<raenye>
but how to create the hierarchy?
<raenye>
no kernel module does it
<linusw>
I would even create a new auxdisplay.mk if I felt ambitious.
Tapper has joined #openwrt-devel
<raenye>
interesting
<raenye>
still I couldn't understand how kmod-sound does it
<linusw>
Looking at it
<linusw>
Looks like you use the SUBMENU:= directive with a defined menu (string) simply?
<linusw>
And add that to everything you want under that submenu? Maybe you tried that already.
<raenye>
that'll place it under the submenu
<linusw>
Ah you mean like that
<raenye>
and DEPENDS make it only visible when the base package is active
<linusw>
So you wanna do like kmod-sound-hda-core does with a subsubmenu?
<raenye>
exactly
<raenye>
or how ac97 is under sound-core
<linusw>
I've never done it but did you notice e.g.: $(call AddDepends/sound,kmod-sound-hda-core)
<raenye>
not sure when DEPENDS means "hide this unless that" and when it means "activate that"
<linusw>
Notice no "+" in front of sound,kmod-sound-hda-core...
<linusw>
Is it such that depends that does not use a + creates a hierarchy?
<raenye>
AddDepends/sound is just a shorthand AFAICT
<raenye>
hmm, maybe that's the thing
<raenye>
good catch
<linusw>
That's the only differing thing I could see ...
<linusw>
Otherwise I'm clueless :/
<raenye>
I'll try without a plus
rua has joined #openwrt-devel
<raenye>
Indeed it now only displays hd44780 if auxdisplay is set
<raenye>
but without hierarchy
<raenye>
but alphabetically
<raenye>
linusw: moreover, I can remove auxdisplay after activating hd44780, which makes little sense
<linusw>
Neat
<linusw>
Hm....
<linusw>
Yeah I don't know who dreamed up the OpenWrt Kconfig-in-Makefile idea, I guess that comes from good old buildroot...
<raenye>
I'm not sure what the $(1) does in AddDepends/sound
<raenye>
maybe it's for the use AddDepends/sound,kmod-sound-hda-core
<raenye>
OK, in a completely separate menu (auxdisplay.mk) it does work as expected
robimarko has quit [Remote host closed the connection]
<linusw>
raenye: good work BTW it's quite appropriate use case for OpenWrt so it's nice you fixed this!
<Mangix>
wonder if someone has tested mt76 wireless on big endian systems
<Mangix>
sounds like a horrible idea.
<jakllsch>
sounds like a awesome idea!
<slh>
I seem to remember someone in here who tested mt7915 on powerpc
<Mangix>
I have an open archer c7v2 with serial hooked up right now. minipcie card is replaceable
<slh>
two major concerns, 10 watts on 3.3V and getting cooling right (that was iirc also the issue on that powerpc system, the card was cooking itself and crashing <-- heatsink and ventilation needed)
<Mangix>
which card?
<slh>
don't ask me for the last details (I just remember it from ~half a year ago in here), but afaik AsiaRF mt7915
<Mangix>
right. that comes in dbdc and non
dgcampea has quit [Remote host closed the connection]
<slh>
in case of the archer c7-v1 I wouldn't bother, I don't think the voltage regulators would handle +10watts on 3.3V - and the case most certainly doesn't have decent enough ventilation (same case as my tl-wdr4300, there's pretty much none) - and if 720 MHz mipq 74Kc can take care of servicing the interrupts for mt7915 is very questionable as well
<Mangix>
interesting. the turris hardware works fine apparently
<slh>
new pigtails probably requierd as well (mhf4)
<slh>
I'd call that good luck (and much higher end hardware with more magrins as well)
<Mangix>
yeah turris hardware is engineered well
<Mangix>
huh interesting. no support for Turris Mox
<Mangix>
tl-wr1043nd v1...is that even supported by recent OpenWrt?
<slh>
yes'ish, 8/32
<Mangix>
I had one before. It was running out of RAM frequently
<slh>
I haven't powered it up in a while though (nor the tl-wr941nd v2)
<Mangix>
ah yes I also remember I overclocked mine too much and bricked it.
<slh>
the tl-wr941nd will go the road to the recycling bin 'soon', I can't really get myself to throw out the tl-wr1043nd v1 yet (and have a faint hope for it to learn DSA via realtek_smi)
<Mangix>
hrm the devices uses non qca switches are all old on ath79
<Mangix>
/s/uses/that use
<slh>
apparently QCA wasn't able to deliver anything early during their ath79 SOC cycle
<Mangix>
makes sense
<slh>
the tl-wr1043nd v1 was a good router back then (the tl-wr941nd v2 less so), its wireless side with draft-n wifi has never been great though - and sadly only 32 MB RAM
<Mangix>
which gives an excuse to give the axe to these old devices
<slh>
my old stack of bcm47xx devices (wrt-54gl, wl-500gx, wl-500gP/ath5k, wrt610nv1) will probably also meet the gauntlet, when I find them again (still boxed up somewhere)
<slh>
then almost everything will be on DSA for me (except ipq807x and the tl-wr1043ndv1)
<Mangix>
ipq807x is not DSA?
<slh>
nope, very similar situation as on ipq40xx-before-DSA
<slh>
very basic switchdev driver
<dwfreed>
I just update my nbg
<dwfreed>
it's still on 19.07
<dwfreed>
s/just/should/
<slh>
dwfreed: r23990-4145ff4d8a (main/2023-09-20) with DSA works well on mine
<slh>
err, sorry, that one didn't have DSA yet, the DSA build is on another computer - but it works
<dwfreed>
ah, that is new-new
<dwfreed>
like, last week new
<slh>
the nbg6817 is great in the sense that it's trivial to recover - and the dual-firmware allows retaining the working/ fully configured old firmware (ideally on the second partition set, as recovering with always rewrite the first)
<dwfreed>
pretty sure my second partition is still factory firmware at the moment :D
<dwfreed>
actually first
<dwfreed>
I'm running off the second
<dwfreed>
I also want to resize the root partitions, that'll be fun
<dwfreed>
I think I remember now, I flashed the same image back again to make it switch back to first partition, so that one day when I was brave enough I could resize the second partition
<slh>
'should work', but... risky the ZyXEL pre-uboot loader has some means to rewrite the eMMC, but undocumented/ no idea how exactly
<dwfreed>
yeah, I was going to do it at first, and then while mucking around, I saw the ZyXEL loader and was scared I'd brick the whole thing, so wanted to have serial capability first
<dwfreed>
then never bought a serial adapter
<dwfreed>
now I have one, just haven't done it
<slh>
same here, I didn't strictly need it so far
<dwfreed>
same
<dwfreed>
worst case I could always extroot to the big partition
<slh>
4 MB for the kernel is more of a constraint long term than the 64 MB for rootfs+overlay
<slh>
not great, considering the 3.2 GB unused space, but well, it's still a router, not a server
<dwfreed>
if I try it, I might try growing that too
<dwfreed>
make it like 8 or 16 MB for kernel, so there's lots of room to grow
<slh>
I always had a dream to use the unused space on the 4 MB spi-nor flash for an initramfs recovery system - but that's veeeery small
<dwfreed>
heh
<Mangix>
I did something similar on a Pogoplug 4 I had once
<slh>
apart from being the wireless driver maintainer, he's employed by QCA - and that's the 75%-official firmware repo for ath10k, getting newer firmware earlier than linux-firmware
<slh>
when it works, the new versions will (eventually) pushed to linux-firmware
<slh>
back then, kvalo updated it once or twice a month with newer versions (while linux-firmware lagged behind quite considerably)
<slh>
looking through all the chipsets I care about (qca4019, qca9887, qca9888, qca988x, qca9984), linux-firmware now is on exactly on the same versions for those - and with the very infrequent updates for ath10k we're seeing now, I'll probably drop it soon