<neggles>
stintel: watchguard M300 question: would the gentoo ppc64 stage3 tarballs work on it?
<neggles>
(whenever you happen to be awake/around :P)
goliath has quit [Quit: SIGSEGV]
SpectreDev_01 has quit [Quit: Connection closed for inactivity]
slh64 has quit [Ping timeout: 480 seconds]
slh has quit [Ping timeout: 480 seconds]
rua has quit [Quit: Leaving.]
bluew has joined #openwrt-devel
f23xhxxx has quit [Quit: WeeChat 4.0.4]
f23xhxxx has joined #openwrt-devel
slh has joined #openwrt-devel
Mangix has joined #openwrt-devel
damex has joined #openwrt-devel
philipp64 has quit [Ping timeout: 480 seconds]
philipp64 has joined #openwrt-devel
<sandberm>
Good morningn. :) Does someone have knowledge on the mt76 driver? The wifi mac address gets to /sys/kernel/debug/ieee80211/phy0/mt76/eeprom alright, but I am trying to figure out where it is physically stored and/or how to expose it to, say, nvmem consumer.
<sandberm>
It's not on flash as far as I can see.
Tapper has joined #openwrt-devel
<PaulFertser>
sandberm: usually you can answer that from device tree.
<PaulFertser>
Or are you talking about a dedicated PCIe card with its own EEPROM?
parazyd has quit [Ping timeout: 480 seconds]
parazyd has joined #openwrt-devel
<sandberm>
PaulFertser: yes, dedicated PCIe card
<PaulFertser>
sandberm: a dedicated card has its own storage, often times a dedicated EEPROM IC right there on the board. MAC address range is bought by the manufacturer of the card and is flashed there during production.
<PaulFertser>
Why would you want it for an nvmem consumer anyway? If it's an "add-on card" and the driver does the right thing reading it and assigning to the network interface what else might you need it for?
<sandberm>
PaulFertser: I tried looking at the mt76 code but it does not give any hits for nvmem_register so I am guessing it does not expose eeprom contents. My situation is such that I can get the label mac from a u-boot env by scripting in 02_network and package/base-files/files/lib/functions/system.sh. I guess the reviewers are not too keen on me touching base-files and I am hatching the idea of getting
<sandberm>
the wifi mac and deducing other macs from it.
<PaulFertser>
sandberm: but you have no right to deduce anything from a MAC of an add-on card.
<PaulFertser>
sandberm: the vendor who flashed that mt76 card allocated just a single address per card.
<PaulFertser>
(could have allocated)
<sandberm>
PaulFertser: hmm. it's not a add-on, it's on a pcie bus, though. but not removable.
<PaulFertser>
sandberm: why does it have dedicated eeprom and all then?
<sandberm>
PaulFertser: or did I miss something. :)
autkin has joined #openwrt-devel
<PaulFertser>
Usually when vendors integrate a card tightly they put all the calibration data and addresses in a dedicated partition on main flash.
<sandberm>
PaulFertser: well that's my assumption atm. the mac is not to be found anywhere on flash but it's preserverved over boots.
slh64 has joined #openwrt-devel
autkin has left #openwrt-devel [#openwrt-devel]
<PaulFertser>
sandberm: there's an nvmem layout that allows you to parse uboot env, isn't that what you need?
<PaulFertser>
sandberm: huh now you're confusing me even more.
<sandberm>
PaulFertser: sorry about that. :) the device has a nand flash and of that the first 1MB has been reserved for u-boot. The rest is ubi formatted and there is there are two u-boot environments. I can get the label mac from a u-boot env variable at the moment. But it requires me to do that scripting in 02_network and system.sh
SpectreDev_01 has joined #openwrt-devel
<SpectreDev_01>
Yep it still reboots, I left it and overnight it has rebooted
<PaulFertser>
sandberm: see e.g. linux/qualcommax/files/arch/arm64/boot/dts/qcom/ipq8072-wax218.dts it's using nvmem layout to fetch variable from u-boot env.
<PaulFertser>
sandberm: so you confirm the card is soldered to the board but does NOT require any calibration data from the main flash?
<PaulFertser>
SpectreDev_01: probably disabling that option for colouring is the next thing to try.
<PaulFertser>
SpectreDev_01: did the script complain about it or was it hostapd?
<SpectreDev_01>
Hostapd was complaining so it killed off WiFi
<SpectreDev_01>
Its randomly rebooted 5hrs ago but system logs won't say why, and it's hovering around 18% free ram right now
<PaulFertser>
Probably unrelated even.
<PaulFertser>
So the config file as it was generated by the uci script was incorrect?
<SpectreDev_01>
Probably yeah
<sandberm>
PaulFertser: the device tree from a running vendor system does not refer to wifi devices at all. And the wifi devices have their macs preserved running openwrt too without me doing any work for it and wifi works also. To me it looks the main flash is not involved at the moment.
<PaulFertser>
SpectreDev_01: can you file a ticket for that please?
<SpectreDev_01>
Eh what past 6hr mark and it's still going fine
autkin has left #openwrt-devel [#openwrt-devel]
autkin has joined #openwrt-devel
<PaulFertser>
sandberm: rootfstype=squashfs shouldn't prevent booting on ubi based devices, no need to delete it.
<PaulFertser>
sandberm: for regular OpenWrt build you're supposed to have rootfs packaged as squashfs and stored on ubi volume named "rootfs".
<PaulFertser>
If vendor bootloader is passing problematic parameters just ignore the whole command line from it.
<PaulFertser>
sandberm: for an mt7621-based board it's really uncommon for wifi cards to have their own eeproms so no wonder the reviewers and you are puzzled about it.
<PaulFertser>
sandberm: there should be no reason to deviate from the OpenWrt way of having rootfs as a squashfs volume.
goliath has joined #openwrt-devel
autkin has left #openwrt-devel [#openwrt-devel]
autkin has joined #openwrt-devel
autkin has left #openwrt-devel [#openwrt-devel]
<stintel>
neggles: I've no idea, never tried
<neggles>
stintel: valid
<neggles>
i can see no reason why it wouldn't
<neggles>
if $friend buys one i'll let you know how it goes :P
<stintel>
:P
<neggles>
if all else fails, openwrt chroot :P
<neggles>
chroot on openwrt i mean
<stintel>
there was some tricky stuff but I think that was musl related
<neggles>
it usually is
<stintel>
it's been a while since I added that target
<stintel>
so don't remember all the details
<neggles>
i got gentoo running on my EdgeRouter Infinity >:D still using the cursed downstream kernel though
<neggles>
why? I like suffering i guess
<neggles>
(16-core octeon III)
<stintel>
hah that reminds me of those octeon based APs I got
<neggles>
yeah i haven't gotten around to flashing mine yet either :P
<stintel>
but haven't done a lot of OpenWrt stuff recently
<neggles>
it's been sitting on the ground next to my desk turned on doing nothing for... some months now
<neggles>
will probably get to it after im done moving
<neggles>
but ye will let you know how M300 goes :P said friend wants something POWER-adjacent and apparently the e6500 supports all the instructions that matter
<stintel>
so I have kernel 6.1 support for qoriq tested, running on both my M300s, 48d uptime on one of them, I rebooted the other for something I don't remember
<stintel>
but there was this discussion on the ML about how to add support for new kernels without breaking git history if you do git log target/linux/qoriq/config-6.1
<sandberm>
PaulFertser: Thank you for the review comments. I tried having a squashfs in ubi volume, but the u-boot does not like it, it expects ubifs in a volume and looks for the uImage and dtb there. I could try rename rootfs_1 'rootfs' but I am afraid the u-boot would not like it either.
<f00b4r0>
sure. But you still loose the history and have to navigate through filenames
<PaulFertser>
sandberm: hm, I suggest you add full "printenv" from u-boot to the "github PR" comments then.
<PaulFertser>
sandberm: so that people could think about how to do it better.
<f00b4r0>
anyhow, I'm not going to fight this battle :)
<sandberm>
PaulFertser: But the fact that I do not set the wifi eeprom location myself and it still works is quite puzzling
<sandberm>
PaulFertser: okies, I will add it.
<PaulFertser>
sandberm: good photos or just you visually inspecting the board and finding additional eeprom ICs would solve the puzzle. Also, dmesg from booting OpenWrt wouldn't hurt in the comments there.
<KanjiMonster>
sure, but that applies to any rename/copy
<KanjiMonster>
detection
SpectreDev_01 has quit [Quit: Connection closed for inactivity]
<f00b4r0>
hence suggesting not to copy/rename :)
<KanjiMonster>
there is no copy or rename in git, only add and remove ;)
<f00b4r0>
...
<f00b4r0>
anyway, the issue is that this makes navigating git blame impossible, which is a convenient way to find out why and when something was changed
<f00b4r0>
but as I said, I rest my case
<KanjiMonster>
why does it make navigating git blame impossible?
<f00b4r0>
iirc git blame doesn't have a --follow
<micw>
Hello. I'm trying to debug my wifi connection issues to provide more information to fix it. At the moment I have one client that has a wifi connection but not traffic. It worked with this client for some days and then suddenly the issue appears.
<KanjiMonster>
I had git blame properly show commits with older paths, probably (again) depends on how well the rename/copy detection works
<micw>
this shows that the ARP requests are answered. but not forwarded to wifi
<PaulFertser>
sandberm: root_vol=rootfs_0 so no collision with "rootfs" that OpenWrt expects. Just make OpenWrt upgrade to store the kernel and dtb there on rootfs_0 and put squashfs in "rootfs", why not?
<stintel>
micw: are you running bridger by chance?
<stintel>
when I was running that I had some issues after some days, I stopped using it since
<micw>
no. I also stopped "dawn" on all devices to exclude it as source of the issues
<sandberm>
PaulFertser: I could be right there, name should not be an issue, given that the failover mechanism does not expect to find rootfs_0 or rootfs_1 in its logic.
<sandberm>
PaulFertser: "I see, you could be right... "
<sandberm>
PaulFertser: That is, if either slot fails to boot for 5 times is shifts over to the other one.
<micw>
I have the impression that DSA is not learning the mac for the wifi interface. there are several other (working clients) where the output of "bridge fdb show" looks like that:
<PaulFertser>
sandberm: OpenWrt only supports using one rootfs anyway, no failover mechanism.
<micw>
5c:cf:7f:00:1a:34 dev wifi-wiot-2g vlan 1003 offload master br-lan
<micw>
so the device where the client is reachable is actually the wifi device. but not for the non-working client
<micw>
this would explain wha the arp responses does not go there
tidalf has joined #openwrt-devel
rz has quit [Ping timeout: 480 seconds]
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]